Fwd: Re: exim and cyrus
Thank you for your answer. I'm using exim 3.35 from debian/stable. What is the advantage of using lmtp? Is it nessassary to use lmtp? I changed my cyrus version now to 2.1 Before I usesd version 1.6. Am Freitag, 31. Januar 2003 18:25 schrieben Sie: 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.
Re: looking for Cyrus mail format documentation
On Tue, Feb 04, 2003 at 02:16:36AM -0500, Rob Siemborski wrote: | On Tue, 4 Feb 2003, Phil Howard wrote: | | Does the RFC say that the IMAP UIDs have to be the file name? | | No, of course not. | | Do the IMAP UIDs have to be the same between different sessions? | | They cannot change without also chanigng the UIDVALIDITY of the mailbox, | which is an expensive operation for disconnected clients (it forces them | to resync) | | So yes, every time you need to resync, you can increment the uidvalidity, | but your disconnected users are going to hate you for it, and this isn't a | tremendously good solution for the real world (where temporary outages | between distant nodes is the norm). So the message with UID 123 during one session has to still have UID 123 during the next session. That indeed will break the ability to have unique remote syncronization. What's curious to me is how, with a Maildir format, that IMAP could be implemented to retain that state without either storing some extra data or updating the files in place. I had thought that real unique message IDs were the same as in RFC 822. I didn't read RFC 2060 because I had been talked out of implementing my own IMAP daemon. But I guess I should have read it, anyway, to understand its limitations. Probably better do that soon before I design something else that can't work :-) -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
how to get thread list in mailing list archive
I'm looking for the description of multiple domains in the archive as someone mentioned. Is there a way to get a list of the threads alone, and not all the messages, like in a fully collapsed form? Since I don't know what keywords to look for, I can't search, and browsing topics is hard with the clutter of all the messages. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: looking for Cyrus mail format documentation
Rob Siemborski wrote: On Sat, 1 Feb 2003, Phil Howard wrote: | Doing replicated IMAP stores (espeically geographicly distanct ones) is | not an easy problem. It's easy if every message is a separate file. This is not true. It has nothing to do with the implementation of the mailstore. I've never actually had the need to try this, so caveat emptor, but I've heard of people having some success replicating Cyrus mailstores with drbd - http://www.complang.tuwien.ac.at/reisner/drbd/. There are limitations to this approach which may make it non-viable for you - your machines would need to be Linux hosts, and you'd need a dedicated network link, but it's the most promising approach I've seen to simple mailstore replication between two machines so far. Mike.
Re: Cyrus IMAPd 2.1.12 Released
On Tue 04 Feb 2003 at 11:00:10 +0700, you wrote: and rpm/srpms was done? http://www.caliban.org/files/redhat Rob Siemborski([EMAIL PROTECTED])@Mon, Feb 03, 2003 at 04:51:00PM -0500: I'm pleased to announce the release of Cyrus IMAPd 2.1.12. This release fixes a significant number of bugs throughout the distribution. Additionally there are the following feature enhancements: * pidfile and daemon-mode support for master * master now requires that the binaries for its services exist and are executable * squatter has an option to skip unmodified mailboxes Additionally, in this release, imapd.c module has received an independent security audit from SecurityAppraisers and Bynari. The distribution is available at: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz Thank you to everyone who contributed to this release. -Rob Ian -- Ian Macdonald | Goto, n.: A programming tool that exists System Administrator| to allow structured programmers to Google, Inc.| complain about unstructured programmers. [EMAIL PROTECTED] | -- Ray Simard 650.330.0100 x1265 |
Authetification HELP!!!
Hi Peter, Sorry, I need your help. I spend a lot of hours with my cyrus server, but I sill have no idea how to solve my problem. I cannot authenticate. I installed cyrus21-admin cyrus21-common, cyrus21-imapd, sasl2-bin on a debian system. I want to set up an autentification via sasldb, cause it seems to be the easiest way. I changed the permission of /etc/sasldb2 to cyrus. I set up imapd.conf # # Debian Cyrus imapd.conf # See imapd.conf(5) for more information and more options # Configuration directory configdirectory: /var/lib/cyrus # Which partition to use for default mailboxes defaultpartition: default partition-default: /var/spool/cyrus/mail # News setup partition-news: /var/spool/cyrus/news newsspool: /var/spool/news # Alternate namespace # If enabled, activate the alternate namespace as documented in # /usr/share/doc/cyrus2-common/html/altnamespace.html, where an user's # subfolders are in the same level as the INBOX altnamespace: no # UNIX Hierarchy Convention # Set to yes, and cyrus will accept dots in names, and use the forward # slash / to delimit levels of the hierarchy. This is done by converting # internally all dots to ^, and all / to dots. So the rabbit.holes # mailbox of user helmer.fudd is stored in user.elmer^fud.rabbit^holes # # WARNING: This option does NOT apply to admin tools such as cyradm # (admins ONLY), reconstruct, quota, etc., NOR does it affect LMTP delivery # of messages directly to mailboxes via plus-addressing. # See also userprefix and sharedprefix on imapd.conf(5) unixhierarchysep: no # Munging illegal characters in headers # Headers of RFC2882 messages must not have characters with the 8th bit # set. However, too many badly-written MUAs generate this, including most # spamware. Disable this if you want Cyrus to leave the crappage untouched # and you don't care that IMAP SEARCH won't work right anymore. #munge8bit: no # Forcing recipient user to lowercase # Cyrus 2.1 is case-sensitive. If all your mail users are in lowercase, it is # probably a very good idea to set lmtp_downcase_rcpt to true. The default is # to assume the user knows what he is doing, and not downcase anything. #lmtp_downcase_rcpt: yes # Uncomment the following and add the space-separated users who # have admin rights for all services. admins: cyrus # Space-separated list of users that have lmtp admin status (i.e. that # can deliver email through TCP/IP lmtp) in addition to those in the # admins: entry above #lmtp_admins: postman # Space-separated list of users that have mupdate admin status, in # addition to those in the admins: entry above. Note that mupdate slaves and # backends in a Murder cluster need to autenticate against the mupdate master # as admin users. #mupdate_admins: mupdateman # Space-separated list of users that have imapd admin status, in # addition to those in the admins: entry above #imap_admins: cyrus # Space-separated list of users that have sieve admin status, in # addition to those in the admins: entry above #sieve_admins: cyrus # List of users and groups that are allowed to proxy for other users, # seperated by spaces. Any user listed in this will be allowed to login # for any other user. Like admins: above, you can have imap_proxyservers # and sieve_proxyservers. #proxyservers: cyrus # No anonymous logins allowanonymouslogin: no # Minimum time between POP mail fetches in minutes popminpoll: 1 # If nonzero, normal users may create their own IMAP accounts by creating # the mailbox INBOX. The user's quota is set to the value if it is positive, # otherwise the user has unlimited quota. autocreatequota: 0 # umask used by Cyrus programs umask: 077 # Sendmail binary location (used by sieve) #sendmail: /usr/sbin/sendmail # If enabled, cyrdeliver will look for Sieve scripts in user's home # directories: ~user/.sieve. sieveusehomedir: false # If sieveusehomedir is false, this directory is searched for Sieve scripts. sievedir: /var/spool/sieve # notifyd(8) method to use for MAIL notifications. If not set, MAIL # notifications are disabled. Valid methods are: null, log, zephyr #mailnotifier: zephyr # notifyd(8) method to use for SIEVE notifications. If not set, SIEVE # notifications are disabled. This method is only used when no method is # specified in the script. Valid methods are null, log, zephyr, mailto #sievenotifier: zephyr # DRAC (pop-before-smtp, imap-before-smtp) support # Set dracinterval to the time in minutes to call DRAC while a user is # connected to the imap/pop services. Set to 0 to disable DRAC (default) # Set drachost to the host where the rpc drac service is running #dracinterval: 0 #drachost: localhost # If enabled, the partitions will also be hashed, in addition to the hashing # done on configuration directories. This is recommended if one partition has a # very bushy mailbox tree. hashimapspool: true # Allow plaintext logins by default (SASL PLAIN) allowplaintext: yes # Force PLAIN/LOGIN authentication only
Re: looking for Cyrus mail format documentation
On Tue, Feb 04, 2003 at 10:19:27AM +, Mike Brodbelt wrote: | Rob Siemborski wrote: | On Sat, 1 Feb 2003, Phil Howard wrote: | | Doing replicated IMAP stores (espeically geographicly distanct ones) is | | not an easy problem. | | It's easy if every message is a separate file. | | This is not true. It has nothing to do with the implementation of the | mailstore. | | I've never actually had the need to try this, so caveat emptor, but I've | heard of people having some success replicating Cyrus mailstores with | drbd - http://www.complang.tuwien.ac.at/reisner/drbd/. | | There are limitations to this approach which may make it non-viable for | you - your machines would need to be Linux hosts, and you'd need a | dedicated network link, but it's the most promising approach I've seen | to simple mailstore replication between two machines so far. I wonder how well that method of replication works when both nodes cannot reach each other, and both are doing updates. And I wonder just how much bandwidth it uses. Suppose one node is connected over a 28.8k analog modem connection because for the rate of SMTP flow in and out, it's enough. Now adding replication delta, will it be any more than what is locally added to the mailstore? I would think the block layer replication would blindly replicate every block on the device that gets changed, rather than a small piece of metadata that would only need to be sent if the replicator understands the meaning of the change. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: looking for Cyrus mail format documentation
On Tue, Feb 04, 2003 at 07:20:57PM +0900, Mark Keasling wrote: | Hi, | | On Tue, 4 Feb 2003 03:19:12 -0600, Phil Howard [EMAIL PROTECTED] wrote... | On Tue, Feb 04, 2003 at 02:16:36AM -0500, Rob Siemborski wrote: | | | On Tue, 4 Feb 2003, Phil Howard wrote: | | | | Does the RFC say that the IMAP UIDs have to be the file name? | | | | No, of course not. | | | | Do the IMAP UIDs have to be the same between different sessions? | | | | They cannot change without also chanigng the UIDVALIDITY of the mailbox, | | which is an expensive operation for disconnected clients (it forces them | | to resync) | | | | So yes, every time you need to resync, you can increment the uidvalidity, | | but your disconnected users are going to hate you for it, and this isn't a | | tremendously good solution for the real world (where temporary outages | | between distant nodes is the norm). | | So the message with UID 123 during one session has to still have UID 123 | during the next session. That indeed will break the ability to have | unique remote syncronization. | | Not really, it just makes it much more complex. When the machines | reconnect, they would need to have a way to determine if the same uid | was referring to two different messages. If so, appending those messages | to the end of the folder with new uids and deleteing the old uid would | re-uniquify the messages. You may want to do that with all of the | messages that two machines received while they were incommunicado. | Essentially, the machines would have to remember their UIDNEXT value at | the time that communication was lost. Once communication was reestablished, | all of the messages from the old UIDNEXT upto the current UIDNEXT held | by each machine would need to be moved (append and delete) to the end of | the folder. The new uids would start from the largest UIDNEXT held by | either machine. I think something like that would workat least in theory. I guess moving them all as a group would help retain the apparent order. | The main problem would be if the two machines appeared to users as | the same machine due to DNS trickery and a user could connect to either | one but the machines still could not connect to each other. (One leg out | of the triangle) In that case, the user's client could see the mailbox | having one message one time and a different message the next even though | the uid was the same. So if the client connected, fetched enough info to | make a message cache list and then disconnected. If the next time it | connected to the other machine to fetch the message, the result would not | be what was expected. The intent was to have a faster machine for road warrier users to connect to while the office is connected via a slow 28.8k analog modem. The idea is to avoid overloading the 28.8k line. And to further help doing that, the outside server would be the internet's MX host (fallback to the inside server anyway), whereas the intranet would see the MX hosts the other way around. Mail from the internet would be delivered on the outside server and replicated in. Mail from the intranet would be delivered on the inside server and replicated out. One thing I was thinking of would be a hack to make one server always use only odd UIDs, and the other always use only even UIDs, and to do catchups while they are reachable with each other. But this is getting into hacking code I know nothing about, yet. Maybe a later time. My original design was for a Maildir based mailstore, and would work at the file replication level (somewhat like rsync, but with some differences to handle it two-ways). -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: looking for Cyrus mail format documentation
On Tue, 04 Feb 2003, Phil Howard wrote: I wonder how well that method of replication works when both nodes cannot reach each other, and both are doing updates. And I wonder They don't. If they cannot reach each other, at most one of them must allow updates. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: looking for Cyrus mail format documentation
Henrique de Moraes Holschuh wrote: On Tue, 04 Feb 2003, Phil Howard wrote: I wonder how well that method of replication works when both nodes cannot reach each other, and both are doing updates. And I wonder They don't. If they cannot reach each other, at most one of them must allow updates. Which, as far as I know, is how all commercial databases also do replication. Only those servers involved in a quorum (even if it is because the primary is treated as having more weight) can accept updates -- the other replicas can only be read-only. Trying to allow arbitrary updates during disconnected operation and then merge the results into a consistent and deterministic state is not just hard, but impossible. For example, if you allow flags to be set differently on the same message on each node, there is no way to resolve the two updates without discarding at least some of the work of one of the sessions. If you carefully constrain the updates that can be performed during disconnected operation (and for consistency that means even not in disconnected operation), then you can transform the problem from impossible to merely extremely difficult. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: looking for Cyrus mail format documentation
On Tue, Feb 04, 2003 at 09:51:21AM -0500, John Alton Tamplin wrote: | Henrique de Moraes Holschuh wrote: | | On Tue, 04 Feb 2003, Phil Howard wrote: | | | I wonder how well that method of replication works when both nodes | cannot reach each other, and both are doing updates. And I wonder | | | They don't. If they cannot reach each other, at most one of them must allow | updates. | | | Which, as far as I know, is how all commercial databases also do | replication. Only those servers involved in a quorum (even if it is | because the primary is treated as having more weight) can accept updates | -- the other replicas can only be read-only. Trying to allow arbitrary | updates during disconnected operation and then merge the results into a | consistent and deterministic state is not just hard, but impossible. | For example, if you allow flags to be set differently on the same | message on each node, there is no way to resolve the two updates without | discarding at least some of the work of one of the sessions. If you | carefully constrain the updates that can be performed during | disconnected operation (and for consistency that means even not in | disconnected operation), then you can transform the problem from | impossible to merely extremely difficult. However, had message IDs been the RFC822 message ID, then it would have been possible to receive new mail on each node. Since the IDs would not collide, that would be OK. If you did get the same ID delivered to both somehow, it should be the same mail. If not, it violates the RFC, so then you decide to replace one of them or change one of them and move on. Deleted mail might be resurrected. But certainly many other things can be a problem, and in the database world, replicators can't really know a lot if the particulars about the data involved, and wouldn't readily be able to do the things you could get away with for email. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: looking for Cyrus mail format documentation
I've been sorta following this thread, and I don't claim to know a whole lot about programming, but I'm wondering why something simple like what I'm about to suggest wouldn't work... Here goes: If a group of servers are gonna be in constant communication, why not just have each server assign UID's in increments of the number of servers in the group? For example, if you have 3 servers, and they realize they've disconnected, each of the servers could number in increments of 3 starting from different points. Assuming the last UID was 502, server 1 would receive messages and number them as 503, 506, 509, etc... Server 2 would number at 504, 507, 510, etc. And Server 3 would number at 505, 508, 511, etc. When the servers re-connect, the file numbers would be unique, the biggest issue you'd run into would be that the incomming sort order will be a little off, and not really. If the user sets their MUA to sort on date, it would be even less of an issue. Why wouldn't something like this work? I mean, assuming that there's some logic involved in the software, the individual servers could figure out which incremented number they could use as their UID next. -peace On Tue, 4 Feb 2003, Mark Keasling wrote: On Tue, 4 Feb 2003 03:19:12 -0600, Phil Howard [EMAIL PROTECTED] wrote... On Tue, Feb 04, 2003 at 02:16:36AM -0500, Rob Siemborski wrote: | On Tue, 4 Feb 2003, Phil Howard wrote: | | Does the RFC say that the IMAP UIDs have to be the file name? | | No, of course not. | | Do the IMAP UIDs have to be the same between different sessions? | | They cannot change without also chanigng the UIDVALIDITY of the mailbox, | which is an expensive operation for disconnected clients (it forces them | to resync) | | So yes, every time you need to resync, you can increment the uidvalidity, | but your disconnected users are going to hate you for it, and this isn't a | tremendously good solution for the real world (where temporary outages | between distant nodes is the norm). So the message with UID 123 during one session has to still have UID 123 during the next session. That indeed will break the ability to have unique remote syncronization. Not really, it just makes it much more complex. When the machines reconnect, they would need to have a way to determine if the same uid was referring to two different messages. If so, appending those messages to the end of the folder with new uids and deleteing the old uid would re-uniquify the messages. You may want to do that with all of the messages that two machines received while they were incommunicado. Essentially, the machines would have to remember their UIDNEXT value at the time that communication was lost. Once communication was reestablished, all of the messages from the old UIDNEXT upto the current UIDNEXT held by each machine would need to be moved (append and delete) to the end of the folder. The new uids would start from the largest UIDNEXT held by either machine. I think something like that would workat least in theory. The main problem would be if the two machines appeared to users as the same machine due to DNS trickery and a user could connect to either one but the machines still could not connect to each other. (One leg out of the triangle) In that case, the user's client could see the mailbox having one message one time and a different message the next even though the uid was the same. So if the client connected, fetched enough info to make a message cache list and then disconnected. If the next time it connected to the other machine to fetch the message, the result would not be what was expected. What's curious to me is how, with a Maildir format, that IMAP could be implemented to retain that state without either storing some extra data or updating the files in place. I had thought that real unique message IDs were the same as in RFC 822. I didn't read RFC 2060 because I had been talked out of implementing my own IMAP daemon. But I guess I should have read it, anyway, to understand its limitations. Probably better do that soon before I design something else that can't work :-) -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| - Regards, Mark Keasling [EMAIL PROTECTED] -- Let he who is without clue kiss my ass
Re: Case sensitve user/mailbox names
Thanks!
Pål
By the way: Do we have to set up this rule as an extra router, or can the
normal Cyrus delivery router take care of the convertion..?
- Original Message -
From: Kevin P. Fleming [EMAIL PROTECTED]
To: Pål Olsen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, February 04, 2003 4:30 PM
Subject: Re: Case sensitve user/mailbox names
Pål Olsen wrote:
Hi,
I've just implemented a new mail platform using Cyrus IMAPd 2.1.11 and
Exim
4.12, and I wonder... how to deal with the fact that systems don't
allways
do want you expect..?
It seem to me that exim/cyrus has problem with delivery of mail if the
mail-address are written in another case than the mailbox-name... E.g.
user
fridao@mydomain can't receive mail if the sender uses mail-address
Fridao@mydomain. How should I deal with that?
I have a router like this in my Exim 4.1x setup talking to Cyrus (at the
appropriate place in the sequence, i.e. just before your Cyrus deliver
router):
lowercase_local:
driver = redirect
domains = +local_domains
redirect_router = local
data = ${lc:${local_part}}
with the Cyrus delivery router being named local.
This message contains information that may be privileged or confidential and is the
property of the Cap Gemini Ernst Young Group. It is intended only for the person to
whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part
thereof. If you receive this message in error, please notify the sender immediately
and delete all copies of this message.
Re: Case sensitve user/mailbox names
Am Dienstag, 4. Februar 2003 15:45 schrieb Pål Olsen: I've just implemented a new mail platform using Cyrus IMAPd 2.1.11 and Exim 4.12, and I wonder... how to deal with the fact that systems don't allways do want you expect..? It seem to me that exim/cyrus has problem with delivery of mail if the mail-address are written in another case than the mailbox-name... E.g. user fridao@mydomain can't receive mail if the sender uses mail-address Fridao@mydomain. How should I deal with that? As long as you don't use the option caseful_local_part in the exim router, exim will send all mails to the lowercase mailbox. Regards, Kerstin
Re: Cyrus IMAPd 2.1.12 Released
Hi,
On Mon, 3 Feb 2003 16:51:00 -0500 (EST)
Rob Siemborski [EMAIL PROTECTED] said:
rjs3 I'm pleased to announce the release of Cyrus IMAPd 2.1.12. This release
I updated my IPv6 support patch for Cyrus IMAPd 2.1.12. You can find
it from:
http://www.imasy.or.jp/~ume/ipv6/cyrus-imapd-2.1.12-ipv6-20030204.diff.gz
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Re: looking for Cyrus mail format documentation
However, had message IDs been the RFC822 message ID, then it would have been possible to receive new mail on each node. Since the IDs would not collide, that would be OK. If you did get the same ID delivered to both somehow, it should be the same mail. If not, it violates the RFC, so then you decide to replace one of them or change one of them and move on. Perhaps the same mail, but with different Received: headers, and possibly with mailing list software headers added. IMO, Message-Id: is not strong enough of a UIDL, *especially* for list owners.
Authentification
Hi, I need some basic information about authentification methods. Where can I find easy to understand information? Thank You Peter
Re: Case sensitve user/mailbox names
Kerstin Espey wrote: As long as you don't use the option caseful_local_part in the exim router, exim will send all mails to the lowercase mailbox. Regards, Kerstin Exim 4.x does not act this way, but Exim 3.x did. If you don't make specific provisions to supply Cyrus a lowercase local part using Exim 4.x, the messages won't get delivered.
Re: how to get thread list in mailing list archive
Date: Tue, 4 Feb 2003 03:55:04 -0600 From: Phil Howard [EMAIL PROTECTED] I'm looking for the description of multiple domains in the archive as someone mentioned. Is there a way to get a list of the threads alone, and not all the messages, like in a fully collapsed form? Since I don't know what keywords to look for, I can't search, and browsing topics is hard with the clutter of all the messages. Our web interface isn't all that sophisticated. You might be happier connecting a real IMAP client to cyrus.andrew.cmu.edu, logging in as anonymous and opening archive.info-cyrus. Hopefully it's a client that can deal with large folders. Larry
Anyone using Linux LVM with cyrus?
Hi all, We're preparing to roll out a new cyrus mail system which will handle the bulk of our 1700 users' email. The server platform will be redhat linux 7.3 or 8.0. We'd like to use the Linux LVM (at the very least for the mail store itself) so that we can back up the system off of read only snapshots (courtesy of LVM). Has anyone out there used LVM with cyrus imap in an environment as large or larger than 1700 users? If so we'd love to hear about any lessons learned (i.e. Don't do it!) or gotchas... Ben
Re: Fwd: Re: exim and cyrus
I don't know about exim 3.35, but I know that exim 3.36 can use LMTP, which we use here. The nicest thing about LMTP is the exim delivers straight, without haveing to call cyrus's deliver. This leads to less overhead, and better overall performance... Also, we switched due to some odd problems with heavy load, and have been very happy with it. Hope this helps, B Peter Burggraef wrote: Thank you for your answer. I'm using exim 3.35 from debian/stable. What is the advantage of using lmtp? Is it nessassary to use lmtp? I changed my cyrus version now to 2.1 Before I usesd version 1.6. Am Freitag, 31. Januar 2003 18:25 schrieben Sie: 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. -- Robert Scussel 1024D/BAF70959/0036 B19E 86CE 181D 0912 5FCC 92D8 1EA1 BAF7 0959
Re: Cyrus IMAPd 2.1.12 Released
Has anyone compiled this successfully on FreeBSD 4.7? I'm getting the following errors: gcc -c -I.. -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 cyrusdb_db3.c cyrusdb_db3.c:87: syntax error before `*' cyrusdb_db3.c:87: warning: type defaults to `int' in declaration of `dbenv' cyrusdb_db3.c:87: warning: data definition has no type or storage class cyrusdb_db3.c:93: syntax error before `*' cyrusdb_db3.c:98: syntax error before `75' cyrusdb_db3.c:98: warning: type defaults to `int' in declaration of `exit' cyrusdb_db3.c:98: conflicting types for `exit' /usr/include/stdlib.h:96: previous declaration of `exit' cyrusdb_db3.c:98: warning: data definition has no type or storage class cyrusdb_db3.c:86: warning: `dbinit' defined but not used cyrusdb_db3.c:90: warning: `commit_txn' declared `static' but never defined cyrusdb_db3.c:91: warning: `abort_txn' declared `static' but never defined *** Error code 1 cyrusdb_db3.c is the same as it was in 2.1.11 which compiles OK. configure was run with the following: ./configure --with-sasl=/usr/local --with-perl --with-auth=unix --with-openss l=/usr/local/ssl --with-duplicate-db=db3_nosync --with-mboxlist-db=skiplist --wi th-seen-db=skiplist --with-subs-db=flat --with-tls-db=db3_nosync These are the same options that 2.1.11 compiles with fine. Using gcc version 2.95.4 20020320 [FreeBSD] on FreeBSD 2.7-RELEASE. Thanks, Chris Scott
Re: Anyone using Linux LVM with cyrus?
On Tue, 2003-02-04 at 20:08, Ben Poliakoff wrote: Hi all, We're preparing to roll out a new cyrus mail system which will handle the bulk of our 1700 users' email. The server platform will be redhat linux 7.3 or 8.0. We'd like to use the Linux LVM (at the very least for the mail store itself) so that we can back up the system off of read only snapshots (courtesy of LVM). Has anyone out there used LVM with cyrus imap in an environment as large or larger than 1700 users? If so we'd love to hear about any lessons learned (i.e. Don't do it!) or gotchas... We decided to use EVMS instead of LVM for one customer's system, because in our opinion, it is more flexible, easy to use for administrators (mainly due to its GUI) and it proved to be a very reliable piece of software (by which I do not imply that LVM isn't). The tools are well designed, consistent, and they do what you expect them to do. There's a GUI, an ncurses-based interface, and a command line tool that is very well suited to scripting. We have an automatic 7-day rotating snapshot system and have already saved some important mails that were accidentally deleted by careless users (would you believe that in Outlook Express you can irreversibly delete a folder with its contents without even seeing a confirmation dialog?). We also have virus scanning and spam filtering in the same box. The hardware is a 1GHz PIII, 512MB of RAM and two 40GB IDE disks in a RAID-1 mirror as data store. The mailstore and snapshots are on the same disks -- thus the snapshots are also RAIDed. We use ext3 as file system, although we are looking very closely at the other journaling filesystems available for Linux at the moment. The user base of this customer is not as large as yours, though, but given this experience we're definately going to move our other customers to this setup as well. I'd say with appropriate hardware to back it up, EVMS would definately by up to the task. Cheers, -- Fabian Fagerholm [EMAIL PROTECTED] paniq.net
Re: Anyone using Linux LVM with cyrus?
Has anyone out there used LVM with cyrus imap in an environment as large or larger than 1700 users? If so we'd love to hear about any lessons learned (i.e. Don't do it!) or gotchas... Ben See a message I posted earlier on a related topic: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrusmsg=20088 -Jules -- Jules Agee System Administrator Pacific Coast Feather Co. [EMAIL PROTECTED] x284
Re: Fwd: Re: exim and cyrus
At 14:18 -0500 Robert Scussel wrote: I don't know about exim 3.35, but I know that exim 3.36 can use LMTP, which we use here. er.. Exim 3.3x can use LMTP over a pipe (ie deliver) or TCP/IP. Exim 4.12 can deliver straight to the lmtpunix socket. Even less overhead (and less packet filtering to worry about) than either of the options for Exim 3. Matt
Issues with Install
I am having 2 problems
1. is with the ./mkimap program.
I am using redhat 8.0 and I get this error
[cyrus@imap tools]$ ./mkimap
reading configure file...
done
Use of uninitialized value in concatenation (.) or string at (eval 1) line
85.
creating ...
Use of uninitialized value in mkdir at (eval 1) line 87.
Use of uninitialized value in chdir at (eval 1) line 91.
Use of chdir('') or chdir(undef) as chdir() is deprecated at (eval 1) line
91.
creating /usr/sieve...
done
that is with perl-5.8.0-55
When I start master
I get:
Feb 4 20:55:26 imap master[15486]: setrlimit: Unable to set file
descriptors limit to -1: Operation not permitted
Feb 4 20:55:26 imap master[15486]: retrying with 1024 (current max)
Feb 4 20:55:26 imap master[15486]: process started
Feb 4 20:55:26 imap master[15487]: about to exec
/usr/cyrus/bin/ctl_cyrusdb
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: recovering cyrus databases
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR db4: : No such file or
directory
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR db4:
/var/imap/db/__db.001: No such file or directory
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR db4: : No such file or
directory
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR db4:
/var/imap/db/__db.001: No such file or directory
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR: dbenv-open
'/var/imap/db' failed: No such file or directory
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR: init /var/imap/db:
cyrusdb error
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR db4: environment not yet
opened
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR: opening
/var/imap/mailboxes.db: Invalid argument
Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR: opening
/var/imap/mailboxes.db: cyrusdb error
Feb 4 20:55:26 imap master[15486]: process 15487 exited, status 75
Feb 4 20:55:26 imap master[15486]: unable to bind socket for service
lmtpunix: No such file or directory
Feb 4 20:55:26 imap master[15486]: ready for work
Feb 4 20:55:26 imap master[15488]: about to exec
/usr/cyrus/bin/ctl_cyrusdb
Feb 4 20:55:26 imap ctl_cyrusdb[15488]: checkpointing cyrus databases
Feb 4 20:55:26 imap ctl_cyrusdb[15488]: DBERROR db4:
/var/imap/db/__db.001: No such file or directory
Feb 4 20:55:26 imap ctl_cyrusdb[15488]: DBERROR: dbenv-open
'/var/imap/db' failed: No such file or directory
Feb 4 20:55:26 imap ctl_cyrusdb[15488]: DBERROR: init /var/imap/db:
cyrusdb error
Feb 4 20:55:26 imap ctl_cyrusdb[15488]: done checkpointing cyrus
databases
Feb 4 20:55:26 imap master[15486]: process 15488 exited, status 1
Does anyone have any ideas?
Re: Issues with Install
On Tue, 4 Feb 2003, lists wrote: I am using redhat 8.0 and I get this error [cyrus@imap tools]$ ./mkimap reading configure file... done Have you set the 'configdirectory' parameter in your /etc/imapd.conf file? It looks like mkimap isn't seeing one, so it's trying to use an empty string instead. This will also explain messages such as Feb 4 20:55:26 imap ctl_cyrusdb[15487]: DBERROR db4: /var/imap/db/__db.001: No such file or directory (in this case master is trying to use /var/imap as the config directory). As well as this there are other things in imapd.conf you need to set - the imapd.conf manpage is a must-read for this. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand
Re: looking for Cyrus mail format documentation
Hi, On Tue, 4 Feb 2003 05:57:53 -0600, Phil Howard [EMAIL PROTECTED] wrote... One thing I was thinking of would be a hack to make one server always use only odd UIDs, and the other always use only even UIDs, and to do catchups while they are reachable with each other. But this is getting into hacking code I know nothing about, yet. Maybe a later time. Using odd and even UIDs and merging would be a novel solution. However, it may be `too' novel. There is an IMAP requirement that doesn't permit merging (reordering). Messages can only be appended to the end of the mailbox because new messages must get a UID = UIDNEXT. The situation is never permitted to occur where the client opens a mailbox which has UIDs 1,3,5 and then at some time later it has UIDs 1,2,3,4,5 with out a change to UIDVALIDITY. When UIDVALIDITY changes (which should be larger than before), the client knows that what it knows about UIDs is now useless. around. Mail from the internet would be delivered on the outside server and replicated in. Mail from the intranet would be delivered on the inside server and replicated out. It could be left at this point; but, I'm sure people would want mail in the same order at both places and changes to be reflected in both places... My original design was for a Maildir based mailstore, and would work at the file replication level (somewhat like rsync, but with some differences to handle it two-ways). It sounds like you may need to design a distributed mailstore that will satisfy both your requirements and those of IMAP and then implement a server around that mailstore. Regards, Mark Keasling [EMAIL PROTECTED]
Re: Issues with Install
lists wrote:
I am having 2 problems
1. is with the ./mkimap program.
I am using redhat 8.0 and I get this error
[cyrus@imap tools]$ ./mkimap
reading configure file...
done
Use of uninitialized value in concatenation (.) or string at (eval 1) line
85.
creating ...
Use of uninitialized value in mkdir at (eval 1) line 87.
Use of uninitialized value in chdir at (eval 1) line 91.
Use of chdir('') or chdir(undef) as chdir() is deprecated at (eval 1) line
91.
creating /usr/sieve...
done
that is with perl-5.8.0-55
Do you run ./mkimap as the cyrus user ?
--Christian--
Re: Cyrus IMAPd 2.1.12 Released
you need to change the db.h to #include /usr/local/include/db3/db.h in cyrusdb_db3.c On Tue, Feb 04, 2003 at 02:34:34PM -0500, Chris Scott wrote: Has anyone compiled this successfully on FreeBSD 4.7? I'm getting the following errors: gcc -c -I.. -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2 cyrusdb_db3.c cyrusdb_db3.c:87: syntax error before `*' cyrusdb_db3.c:87: warning: type defaults to `int' in declaration of `dbenv' cyrusdb_db3.c:87: warning: data definition has no type or storage class cyrusdb_db3.c:93: syntax error before `*' cyrusdb_db3.c:98: syntax error before `75' cyrusdb_db3.c:98: warning: type defaults to `int' in declaration of `exit' cyrusdb_db3.c:98: conflicting types for `exit' /usr/include/stdlib.h:96: previous declaration of `exit' cyrusdb_db3.c:98: warning: data definition has no type or storage class cyrusdb_db3.c:86: warning: `dbinit' defined but not used cyrusdb_db3.c:90: warning: `commit_txn' declared `static' but never defined cyrusdb_db3.c:91: warning: `abort_txn' declared `static' but never defined *** Error code 1 cyrusdb_db3.c is the same as it was in 2.1.11 which compiles OK. configure was run with the following: ./configure --with-sasl=/usr/local --with-perl --with-auth=unix --with-openss l=/usr/local/ssl --with-duplicate-db=db3_nosync --with-mboxlist-db=skiplist --wi th-seen-db=skiplist --with-subs-db=flat --with-tls-db=db3_nosync These are the same options that 2.1.11 compiles with fine. Using gcc version 2.95.4 20020320 [FreeBSD] on FreeBSD 2.7-RELEASE. Thanks, Chris Scott
Re: looking for Cyrus mail format documentation
you stated that you want to have the outside box act as a secondary MX for the inside one, if you do this and accept the extra bandwidth used then you could still do this and have the mail only delivered to the inside box and then replicated out to the outside one. this doesn't solve the problem of changing flags, but does solve the problem of getting the messages in correctly. for the flags the real question is do you HAVE to allow them to be updated when the primary can't be reached? or can your users tolorate being able to see their mail, but not have the flags change if you have a connection problem? (or possibly allow some flags to be changed and queued up, seen flags can be reconsiled by changing both sides to the the or of the two when they reconnect, deletes can be queued and processed later, etc) there are some useage patterns here that can narrow the scope of the limitation more then the generic database two-way-sync problem David Lang On Tue, 4 Feb 2003, Phil Howard wrote: Date: Tue, 4 Feb 2003 03:19:12 -0600 From: Phil Howard [EMAIL PROTECTED] To: Rob Siemborski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: looking for Cyrus mail format documentation On Tue, Feb 04, 2003 at 02:16:36AM -0500, Rob Siemborski wrote: | On Tue, 4 Feb 2003, Phil Howard wrote: | | Does the RFC say that the IMAP UIDs have to be the file name? | | No, of course not. | | Do the IMAP UIDs have to be the same between different sessions? | | They cannot change without also chanigng the UIDVALIDITY of the mailbox, | which is an expensive operation for disconnected clients (it forces them | to resync) | | So yes, every time you need to resync, you can increment the uidvalidity, | but your disconnected users are going to hate you for it, and this isn't a | tremendously good solution for the real world (where temporary outages | between distant nodes is the norm). So the message with UID 123 during one session has to still have UID 123 during the next session. That indeed will break the ability to have unique remote syncronization. What's curious to me is how, with a Maildir format, that IMAP could be implemented to retain that state without either storing some extra data or updating the files in place. I had thought that real unique message IDs were the same as in RFC 822. I didn't read RFC 2060 because I had been talked out of implementing my own IMAP daemon. But I guess I should have read it, anyway, to understand its limitations. Probably better do that soon before I design something else that can't work :-) -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
cyradm not working on a working cyrus /2.1.112.1.12
As on version 2.1.11 i get cyrus up und running without any problem - except cyradm. A call of cyradm brings out the mentionned error msg. if i copy shell.pm in the path, a new prompt line results, nothing happens at all. Does anybody know about this issue? Is there another possibility to administer the cyrus mailboxes? error msg: Shell.pm not found @INC (followed by the path list...) System: Redhat 8.0 Sasl: 2.1.11 Berkeley DB: db4 /db4 devel thx Roger
