Re: MURDER or IMAP proxy solution ?
--- Jim Levie <[EMAIL PROTECTED]> wrote: > I'd agree with that in ordinary mail environment, > but not necessarily at > an ISP. In my experience there's significantly more > work & training > involved with the account management part than just > server setup. > Changing from a single server to an aggregator would > mean re-writing the > account maintenance scripts and re-training help > desk folks, etc. So if > I anticipated needing an aggregator in the future > for scaling or > availability I's start with one. That's what we thought too, I would also prefer to get all the complicated stuff sorted out right ahead and this will also give some kind of experience with MURDER when we still are small and where inexperience human errors would not have a bad impact. Anyway we are going to start small, one backend server and one frontend server with Sendmail and MUPDATE server running directly on it. Thanks again too all of you guys who gave me their opinion ! Regards __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Importing mbox to Cyrus
On Mon, 2004-07-05 at 13:14, Allen Unueco wrote: [snip] > I've found a few mbox2imap scripts and but none of them work completely. The > one from http://teyandei.net/projects worked the best, but on the two large > mbox files I've tried both exited out with an error during imap.append() > claiming the email had a bad header. I wish I could get some more detailed info > regarding the 'bad header' but thats all I get. I do wish the Cyrus error message would include something that identified the header and message ... but I suppose that's really the client's problem. Clients should print this info when they print an error about a failed message insertion. Most, unfortunately, don't. [snip] > Has anyone had these problems before? Yep. > What is the best way to bring legacy email into Cyrus? I found mailutil from the uw-imap distribution did the trick fine. If you run it in verbose mode, it'll also let you identify what message it's complaining about when you get errors about bad headers or messages containing NULL characters. I was migrating from another IMAP server, but it's probably even easier from mbox because you can easily fix the mbox files. -- Craig Ringer --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
ANNOTATEMORE Patch submission
Dear all,
Please find attached two patches for the ANNOTATEMORE facility of Cyrus IMAP.
Patch one adds /vendor/kolab support to Cyrus, I am submitting it on behalf of
the Kolab developers and partners. We will be using ANNOTATEMORE to identify
folder types, and would greatly appreciate the addition of our vendor tag into
Cyrus IMAP. Our IANA OID is 19414 for reference...
The second patch is optional, and more of a suggestion from the Kolab developers.
This will add support for /vendor/* to ANNOTATEMORE. Maybe it is worthwhile
considering this option, it should not have any foreseeable negative impact on
the server, and going forward it would add a lot of flexibility to the ANNOTAMORE
function, thus speeding up adoption thereoff.
For any interested parties the work related to this patch is being actively
discussed at:
http://www.kolab.org/mailman/listinfo/kolab-format
On behalf of the Kolab developers. (http://www.kolab.org)
Kind regards,
--
Stephan Buys
--- annotate.c.old 2004-07-02 18:13:13.0 +0200
+++ annotate.c 2004-07-02 18:17:19.0 +0200
@@ -1595,6 +1595,8 @@
{ "/vendor/cmu/cyrus-imapd/news2mail", ATTRIB_TYPE_STRING, BACKEND_ONLY,
ATTRIB_VALUE_SHARED | ATTRIB_CONTENTTYPE_SHARED,
ACL_ADMIN, annotation_set_todb, NULL },
+{ "/vendor/kolab/foldertype", ATTRIB_TYPE_STRING, BACKEND_ONLY,
+ ATTRIB_VALUE_SHARED, ACL_ADMIN, annotation_set_todb, NULL },
{ NULL, 0, ANNOTATION_PROXY_T_INVALID, 0, 0, NULL, NULL }
};
--- annotate.c.old 2004-07-02 18:13:13.0 +0200
+++ annotate.c 2004-07-03 10:20:17.0 +0200
@@ -1598,6 +1598,11 @@
{ NULL, 0, ANNOTATION_PROXY_T_INVALID, 0, 0, NULL, NULL }
};
+const struct annotate_st_entry vendor_entry =
+{ NULL, ATTRIB_TYPE_STRING, BACKEND_ONLY,
+ ATTRIB_VALUE_SHARED | ATTRIB_VALUE_PRIV,
+ ACL_ADMIN, annotation_set_todb, NULL };
+
int annotatemore_store(char *mailbox,
struct entryattlist *l,
struct namespace *namespace,
@@ -1610,6 +1615,7 @@
struct attvaluelist *av;
struct storedata sdata;
const struct annotate_st_entry *entries;
+struct annotate_st_entry * working_entry;
time_t now = time(0);
memset(&sdata, 0, sizeof(struct storedata));
@@ -1631,37 +1637,55 @@
while (e) {
int entrycount, attribs;
struct annotate_st_entry_list *nentry = NULL;
+ struct annotate_st_entry *ientry = NULL;
/* See if we support this entry */
+ working_entry = NULL;
for (entrycount = 0;
entries[entrycount].name;
entrycount++) {
if (!strcmp(e->entry, entries[entrycount].name)) {
+ working_entry = &(entries[entrycount]);
break;
}
}
- if (!entries[entrycount].name) {
- /* unknown annotation */
- return IMAP_PERMISSION_DENIED;
+ if (working_entry==NULL) {
+ /* test for generic vendor annotation */
+ if ((strncmp("/vendor/", e->entry, strlen("/vendor/"))==0) &&
+ (strlen(e->entry)>strlen("/vendor/"))) {
+ working_entry = &(vendor_entry);
+ }
+ else {
+ /* unknown annotation */
+ return IMAP_PERMISSION_DENIED;
+ }
}
/* Add this entry to our list only if it
applies to our particular server type */
- if (entries[entrycount].proxytype == PROXY_AND_BACKEND
+ if (working_entry->proxytype == PROXY_AND_BACKEND
|| (proxy_store_func &&
- entries[entrycount].proxytype == PROXY_ONLY)
+ working_entry->proxytype == PROXY_ONLY)
|| (!proxy_store_func &&
- entries[entrycount].proxytype == BACKEND_ONLY)) {
+ working_entry->proxytype == BACKEND_ONLY)) {
+ientry = xzmalloc(sizeof(struct annotate_st_entry));
+ientry->name = e->entry;
+ientry->type = working_entry->type;
+ientry->proxytype = working_entry->proxytype;
+ientry->attribs = working_entry->attribs;
+ientry->acl = working_entry->acl;
+ientry->set = working_entry->set;
+ientry->rock = working_entry->rock;
nentry = xzmalloc(sizeof(struct annotate_st_entry_list));
nentry->next = sdata.entry_list;
- nentry->entry = &(entries[entrycount]);
+ nentry->entry = ientry;
nentry->shared.modifiedsince = now;
nentry->priv.modifiedsince = now;
sdata.entry_list = nentry;
}
/* See if we are allowed to set the given attributes. */
- attribs = entries[entrycount].attribs;
+ attribs = working_entry->attribs;
av = e->attvalues;
while (av) {
const char *value;
@@ -1671,7 +1695,7 @@
goto cleanup;
}
value = annotate_canon_value(av->value,
- entries[entrycount].type);
+ working_entry->type);
if (!value) {
r = IMAP_ANNOTATION_BADVALUE;
goto cleanup;
@@ -1697,7 +1721,7 @@
goto cleanup;
}
value = annotate_canon_value(av->value,
- entries[entrycount].type);
+ working_entry->type);
if (!value) {
r = IMAP_ANNOTATION_BADVALUE;
goto cleanup;
@@ -1797,6 +1821,12 @@
/* Free
Re: Vanishing quota information
Simon Matter wrote: Jure Peèar wrote: On Sun, 4 Jul 2004 20:08:27 +0200 (CEST) "Simon Matter" <[EMAIL PROTECTED]> wrote: I had the same. Looks like somehow the information stored in the quota file was wrong and has been corrected. I didn't have this problem again with the patches 2.2.6 server. I'm saying that the quota file was 'corrected' to some number that is 5 to 7 times larger that the real size of the mailbox ... and this is happening with the lib/cyrusdb_quotalegacy.c (rev 1.1.2.6) and imap/quota.c (rev 1.48.2.6) from the cvs. We have quotas set at 10Mb, so it is unreasonable to see most of the mailboxes reporting usage around 60Mb ... Another problem which I can't reproduce. Is it possible that its mistakenly adding the usage of multiple users within the virtdomain? What I meant was that I also had the problem that quota have been corrected when running quota -f. I also had the problem of wrong calculated quota with the unpatched 2.2.6, but not with the patched one. For the vanishing quota problem, it seems that the problem is from a bug in one of the patches I include in my rpms, not from cyrus-imapd itself. I'll provide more information after further investigation. So you're saying that current CVS works fine for quota -f? -- 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 --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: encoded packet size too big
Jukka Salmi --> info-cyrus (2004-07-01 23:33:16 +0200): > When authenticating with GSSAPI I can't upload Sieve script larger > than about 4k bytes: To be more accurate, it's "larger than 4000 bytes". > sieve[7228]: encoded packet size too big (4107 > 4096) Applying [1] solved my problem... Jukka [1] https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/sasl/plugins/gssapi.c.diff?r1=1.84&r2=1.85 -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~ --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Vanishing quota information
> Simon Matter wrote: > >>>Jure Peèar wrote: >>> >>> On Sun, 4 Jul 2004 20:08:27 +0200 (CEST) "Simon Matter" <[EMAIL PROTECTED]> wrote: >I had the same. Looks like somehow the information stored in the quota >file was wrong and has been corrected. I didn't have this problem > again >with the patches 2.2.6 server. I'm saying that the quota file was 'corrected' to some number that is 5 to 7 times larger that the real size of the mailbox ... and this is happening with the lib/cyrusdb_quotalegacy.c (rev 1.1.2.6) and imap/quota.c (rev 1.48.2.6) from the cvs. We have quotas set at 10Mb, so it is unreasonable to see most of the mailboxes reporting usage around 60Mb ... >>> >>>Another problem which I can't reproduce. Is it possible that its >>>mistakenly adding the usage of multiple users within the virtdomain? >> >> >> What I meant was that I also had the problem that quota have been >> corrected when running quota -f. I also had the problem of wrong >> calculated quota with the unpatched 2.2.6, but not with the patched one. >> >> For the vanishing quota problem, it seems that the problem is from a bug >> in one of the patches I include in my rpms, not from cyrus-imapd itself. >> I'll provide more information after further investigation. > > So you're saying that current CVS works fine for quota -f? Yes, the CVS version works fine now. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Open file limits
Hi, Can anyone share experiences with running out of open files on Linux? I am using a 2.4.26 kernel, and the system wide open file limit is rather large. Do I need to set anything other than this? The default limit of 1024 is in effect for both cyrus and root. Thanks. AJ --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
