From wes at umich.edu Mon Jun 2 14:45:28 2008 From: wes at umich.edu (Wesley Craig) Date: Mon, 2 Jun 2008 14:45:28 -0400 Subject: ptclient & ldap changes In-Reply-To: <4841C239.6040807@ypass.net> References: <48403E71.2030603@ypass.net> <4D33877B-28E3-4294-BA99-30E38FE9371F@umich.edu> <4840CED4.70607@ypass.net> <21D95F9A-BAFE-4697-AFDA-0F849934D28C@umich.edu> <4841C239.6040807@ypass.net> Message-ID: On 31 May 2008, at 17:25, Igor Brezac wrote: > Wesley Craig wrote: >> On 31 May 2008, at 00:06, Igor Brezac wrote: >>> sasl used to be required for ldap proxy authz, but I do not think >>> this is the case any more. I suggested that both ldap_sasl and >>> ldap_proxy_authz do the same thing. >> >> Perhaps I misunderstand you. Since SASL authN and proxy authZ are >> more or less completely orthogonal, why would you have them do the >> same thing? I propose that ldap_sasl control the way bind is >> done. And ldap_proxy_authz is used to control how user DNs are >> obtained. > Your patch breaks existing configurations, we usually try to > preserve configuration compatibility when possible. Otherwise I am > fine with your approach. Maybe automatically set ldap_proxy_authz > to true when ldap_sasl is turned on and when ldap_proxy_authz is > not explicitly specified in the config? Well, that's an issue. We could make ldap_proxy_authz tri-valued: legacy, on, and off. Legacy would be the default and would revert to the old behavior. Of course, that means that it wouldn't support imapd.conf's typical 0/1, on/off, t/f "switch" syntax. > True, although it is broken when values of ldap_member_attribute > are represented with DN. You are probably right, not worth messing > with. I feel as tho if ldap_member_attribute is a DN, then maybe the proper scheme is ldap_member_method: filter. Obviously, if the group entry doesn't have a reference to the members, that won't work. But I think that jibes with my point the pt/ldap supports (more or less) two schemes for group membership. Adding a variation on the (already kind of broken) ldap_member_method: attribute scheme which dereferences ldap_member_attribute's when they are DNs is a good feature. Someone should need that feature, tho :) >> LDAP_NO_LIMIT might be a useful way to handle this case, but >> you're still left wondering how to handle the case where the >> server's size limit is exceeded. Do I populate what I got back? >> Do I populate nothing? > > I suppose LDAP_NO_LIMIT is lesser of two evils. It seems > impractical for a user to be member of several hundred groups... The complement is not true, tho: it's very practical in the ldap_member_method: attribute scheme for there to be a lot of users in a given group. Perhaps the configurable size limit option should be removed. If ldap_member_method is filter, there should be no (LDAP client imposed) size limit. If ldap_member_method is attribute, the limit should be 1. :wes From murch at andrew.cmu.edu Mon Jun 2 22:50:26 2008 From: murch at andrew.cmu.edu (Ken Murchison) Date: Mon, 02 Jun 2008 22:50:26 -0400 Subject: ptclient & ldap changes In-Reply-To: References: <48403E71.2030603@ypass.net> <4D33877B-28E3-4294-BA99-30E38FE9371F@umich.edu> <4840CED4.70607@ypass.net> <21D95F9A-BAFE-4697-AFDA-0F849934D28C@umich.edu> <4841C239.6040807@ypass.net> Message-ID: <4844B172.2030303@andrew.cmu.edu> Wesley Craig wrote: > On 31 May 2008, at 17:25, Igor Brezac wrote: >> Wesley Craig wrote: >>> On 31 May 2008, at 00:06, Igor Brezac wrote: >>>> sasl used to be required for ldap proxy authz, but I do not think >>>> this is the case any more. I suggested that both ldap_sasl and >>>> ldap_proxy_authz do the same thing. >>> >>> Perhaps I misunderstand you. Since SASL authN and proxy authZ are >>> more or less completely orthogonal, why would you have them do the >>> same thing? I propose that ldap_sasl control the way bind is done. >>> And ldap_proxy_authz is used to control how user DNs are obtained. >> Your patch breaks existing configurations, we usually try to preserve >> configuration compatibility when possible. Otherwise I am fine with >> your approach. Maybe automatically set ldap_proxy_authz to true when >> ldap_sasl is turned on and when ldap_proxy_authz is not explicitly >> specified in the config? > > Well, that's an issue. We could make ldap_proxy_authz tri-valued: > legacy, on, and off. Legacy would be the default and would revert to > the old behavior. Of course, that means that it wouldn't support > imapd.conf's typical 0/1, on/off, t/f "switch" syntax. vritdomains is tri-valued, so I wouldn't have a problem with your proposal. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From igor at ypass.net Mon Jun 2 23:14:29 2008 From: igor at ypass.net (Igor Brezac) Date: Mon, 02 Jun 2008 23:14:29 -0400 Subject: ptclient & ldap changes In-Reply-To: References: <48403E71.2030603@ypass.net> <4D33877B-28E3-4294-BA99-30E38FE9371F@umich.edu> <4840CED4.70607@ypass.net> <21D95F9A-BAFE-4697-AFDA-0F849934D28C@umich.edu> <4841C239.6040807@ypass.net> Message-ID: <4844B715.4000107@ypass.net> Wesley Craig wrote: > On 31 May 2008, at 17:25, Igor Brezac wrote: >> Wesley Craig wrote: >>> On 31 May 2008, at 00:06, Igor Brezac wrote: >>>> sasl used to be required for ldap proxy authz, but I do not think >>>> this is the case any more. I suggested that both ldap_sasl and >>>> ldap_proxy_authz do the same thing. >>> >>> Perhaps I misunderstand you. Since SASL authN and proxy authZ are >>> more or less completely orthogonal, why would you have them do the >>> same thing? I propose that ldap_sasl control the way bind is done. >>> And ldap_proxy_authz is used to control how user DNs are obtained. >> Your patch breaks existing configurations, we usually try to preserve >> configuration compatibility when possible. Otherwise I am fine with >> your approach. Maybe automatically set ldap_proxy_authz to true >> when ldap_sasl is turned on and when ldap_proxy_authz is not >> explicitly specified in the config? > > Well, that's an issue. We could make ldap_proxy_authz tri-valued: > legacy, on, and off. Legacy would be the default and would revert to > the old behavior. Of course, that means that it wouldn't support > imapd.conf's typical 0/1, on/off, t/f "switch" syntax. > That'll work. >>> LDAP_NO_LIMIT might be a useful way to handle this case, but you're >>> still left wondering how to handle the case where the server's size >>> limit is exceeded. Do I populate what I got back? Do I populate >>> nothing? >> >> I suppose LDAP_NO_LIMIT is lesser of two evils. It seems impractical >> for a user to be member of several hundred groups... > > The complement is not true, tho: it's very practical in the > ldap_member_method: attribute scheme for there to be a lot of users in > a given group. Perhaps the configurable size limit option should be > removed. If ldap_member_method is filter, there should be no (LDAP > client imposed) size limit. If ldap_member_method is attribute, the > limit should be 1. > I like this suggestion. -Igor From Valery.Brasseur at atosorigin.com Wed Jun 4 04:47:55 2008 From: Valery.Brasseur at atosorigin.com (Brasseur Valery) Date: Wed, 4 Jun 2008 10:47:55 +0200 Subject: bug in the proxy module ... Message-ID: Hi, I am using cyrus 2.3.11 in a murder setup... from time to time have got an hang from the pop3 proxyd ... I nail it donw to the following portion of code : in imap/proxy.c near line 266 : if (pout) { const char *err; char buf[4096]; int c; do { c = prot_read(pin, buf, sizeof(buf)); if (c == 0 || c < 0) break; prot_write(pout, buf, c); } while (c == sizeof(buf)); if ((err = prot_error(pin)) != NULL) { from time to time, the prot_read return exactly 4096 bytes, but it's the end of the message... so backend seat and wait for next command, and proxy seat and wait for the next buffer ... forever ! for me it's seems that the condition " c == sizeof(buf)" is not enough in that case. have someone else already encoutered this ? thanks valery Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. From jreich at jreich.com Wed Jun 4 09:31:30 2008 From: jreich at jreich.com (Julian Reich) Date: Wed, 4 Jun 2008 15:31:30 +0200 Subject: Bug in mboxlist_mycreatemailboxcheck() Message-ID: <80B2F0C9-EA11-4410-9025-A0728C4EE706@jreich.com> Hi, a buggy check in mboxlist_mycreatemailboxcheck() allows authenticated users that not yet have an inbox to create it whether autocreatequota is set to 0 or not. The user is then granted unlimited storage. This only happens when virtdomains is not set to off and the domain contains at least one dot. The issue can easily be fixed by using the "local" mailbox name for doing the check instead of the fully qualified. Yours, Julian Reich -------------- next part -------------- A non-text attachment was scrubbed... Name: cyrus-imapd-virtdomains-createmailbox.patch Type: application/octet-stream Size: 731 bytes Desc: not available Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20080604/2354455f/attachment.obj -------------- next part -------------- From Valery.Brasseur at atosorigin.com Mon Jun 9 08:52:09 2008 From: Valery.Brasseur at atosorigin.com (Brasseur Valery) Date: Mon, 9 Jun 2008 14:52:09 +0200 Subject: bug in the proxy module ... Message-ID: Hi, I am using cyrus 2.3.11 in a murder setup... from time to time have got an hang from the pop3 proxyd ... I nail it donw to the following portion of code : in imap/proxy.c near line 266 : if (pout) { const char *err; char buf[4096]; int c; do { c = prot_read(pin, buf, sizeof(buf)); if (c == 0 || c < 0) break; prot_write(pout, buf, c); } while (c == sizeof(buf)); if ((err = prot_error(pin)) != NULL) { from time to time, the prot_read return exactly 4096 bytes, but it's the end of the message... so backend seat and wait for next command, and proxy seat and wait for the next buffer ... forever ! for me it's seems that the condition " c == sizeof(buf)" is not enough in that case. have someone else already encoutered this ? thanks valery Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. From murch at andrew.cmu.edu Mon Jun 9 14:45:55 2008 From: murch at andrew.cmu.edu (Ken Murchison) Date: Mon, 09 Jun 2008 14:45:55 -0400 Subject: bug in the proxy module ... In-Reply-To: References: Message-ID: <484D7A63.5060305@andrew.cmu.edu> I haven't run into this, but you can try changing the while clause to: while (c == sizeof(buf) && buf[sizeof(buf)-1] != '\n') This is completely untested and may have unintended side-effects. Brasseur Valery wrote: > Hi, > > I am using cyrus 2.3.11 in a murder setup... from time to time have got an hang from the pop3 proxyd ... > > I nail it donw to the following portion of code : > in imap/proxy.c near line 266 : > > if (pout) { > const char *err; > char buf[4096]; > int c; > > do { > c = prot_read(pin, buf, sizeof(buf)); > > if (c == 0 || c < 0) break; > prot_write(pout, buf, c); > } while (c == sizeof(buf)); > > if ((err = prot_error(pin)) != NULL) { > > from time to time, the prot_read return exactly 4096 bytes, but it's the end of the message... > so backend seat and wait for next command, and proxy seat and wait for the next buffer ... > forever ! > > for me it's seems that the condition " c == sizeof(buf)" is not enough in that case. > > > > have someone else already encoutered this ? > > > thanks > valery > > > > > Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. > > -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From wes at umich.edu Mon Jun 9 15:29:15 2008 From: wes at umich.edu (Wesley Craig) Date: Mon, 9 Jun 2008 15:29:15 -0400 Subject: bug in the proxy module ... In-Reply-To: References: Message-ID: <4B9DAB02-1117-4349-AD5C-38E4278AABE7@umich.edu> Looks like this change: https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/ proxy.c.diff?r1=1.3;r2=1.4 is in error. The old code was wrong, but this change is also wrong. :wes On 09 Jun 2008, at 08:52, Brasseur Valery wrote: > I am using cyrus 2.3.11 in a murder setup... from time to time have > got an hang from the pop3 proxyd ... > > I nail it donw to the following portion of code : > in imap/proxy.c near line 266 : > > if (pout) { > const char *err; > char buf[4096]; > int c; > > do { > c = prot_read(pin, buf, sizeof(buf)); > > if (c == 0 || c < 0) break; > prot_write(pout, buf, c); > } while (c == sizeof(buf)); > > if ((err = prot_error(pin)) != NULL) { > > from time to time, the prot_read return exactly 4096 bytes, but > it's the end of the message... > so backend seat and wait for next command, and proxy seat and wait > for the next buffer ... > forever ! > > for me it's seems that the condition " c == sizeof(buf)" is not > enough in that case. From murch at andrew.cmu.edu Tue Jun 10 10:07:39 2008 From: murch at andrew.cmu.edu (Ken Murchison) Date: Tue, 10 Jun 2008 10:07:39 -0400 Subject: bug in the proxy module ... In-Reply-To: <4B9DAB02-1117-4349-AD5C-38E4278AABE7@umich.edu> References: <4B9DAB02-1117-4349-AD5C-38E4278AABE7@umich.edu> Message-ID: <484E8AAB.6000305@andrew.cmu.edu> Any suggestions? I'm off thinking about other things at the moment. Wesley Craig wrote: > Looks like this change: > > https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/proxy.c.diff?r1=1.3;r2=1.4 > > > is in error. The old code was wrong, but this change is also wrong. > > :wes > > On 09 Jun 2008, at 08:52, Brasseur Valery wrote: >> I am using cyrus 2.3.11 in a murder setup... from time to time have >> got an hang from the pop3 proxyd ... >> >> I nail it donw to the following portion of code : >> in imap/proxy.c near line 266 : >> >> if (pout) { >> const char *err; >> char buf[4096]; >> int c; >> >> do { >> c = prot_read(pin, buf, sizeof(buf)); >> >> if (c == 0 || c < 0) break; >> prot_write(pout, buf, c); >> } while (c == sizeof(buf)); >> >> if ((err = prot_error(pin)) != NULL) { >> >> from time to time, the prot_read return exactly 4096 bytes, but it's >> the end of the message... >> so backend seat and wait for next command, and proxy seat and wait for >> the next buffer ... >> forever ! >> >> for me it's seems that the condition " c == sizeof(buf)" is not enough >> in that case. > -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From Valery.Brasseur at atosorigin.com Wed Jun 11 03:11:01 2008 From: Valery.Brasseur at atosorigin.com (Brasseur Valery) Date: Wed, 11 Jun 2008 09:11:01 +0200 Subject: bug in the proxy module ... In-Reply-To: <484D7A63.5060305@andrew.cmu.edu> References: <484D7A63.5060305@andrew.cmu.edu> Message-ID: Well, I would go for : while (c == sizeof(buf) && ( buf[sizeof(buf)-1] != '\n' || buf[sizeof(buf)-2] != '\r' || buf[sizeof(buf)-3] != '.' || buf[sizeof(buf)-4] != '\n') ) as I think that checking for '\n' is no enought. > -----Message d'origine----- > De : Ken Murchison [mailto:murch at andrew.cmu.edu] > Envoy? : lundi 9 juin 2008 20:46 > ? : Brasseur Valery > Cc : cyrus-devel at lists.andrew.cmu.edu > Objet : Re: bug in the proxy module ... > > I haven't run into this, but you can try changing the while clause to: > > while (c == sizeof(buf) && buf[sizeof(buf)-1] != '\n') > > This is completely untested and may have unintended side-effects. > > > Brasseur Valery wrote: > > Hi, > > > > I am using cyrus 2.3.11 in a murder setup... from time to time have > got an hang from the pop3 proxyd ... > > > > I nail it donw to the following portion of code : > > in imap/proxy.c near line 266 : > > > > if (pout) { > > const char *err; > > char buf[4096]; > > int c; > > > > do { > > c = prot_read(pin, buf, sizeof(buf)); > > > > if (c == 0 || c < 0) break; > > prot_write(pout, buf, c); > > } while (c == sizeof(buf)); > > > > if ((err = prot_error(pin)) != NULL) { > > > > from time to time, the prot_read return exactly 4096 bytes, but it's > the end of the message... > > so backend seat and wait for next command, and proxy seat and wait > for the next buffer ... > > forever ! > > > > for me it's seems that the condition " c == sizeof(buf)" is not > enough in that case. > > > > > > > > have someone else already encoutered this ? > > > > > > thanks > > valery > > > > > > > > > > Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? > l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? > par le secret professionnel. Si vous recevez ce message par erreur, > merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. > L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la > responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au > contenu de ce message. Bien que les meilleurs efforts soient faits pour > maintenir cette transmission exempte de tout virus, l'exp?diteur ne > donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre > recherch?e pour tout dommage r?sultant d'un virus transmis. > > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy > it. As its integrity cannot be secured on the Internet, the Atos Origin > group liability cannot be triggered for the message content. Although > the sender endeavours to maintain a computer virus-free network, the > sender does not warrant that this transmission is virus-free and will > not be liable for any damages resulting from any virus transmitted. > > > > > > > -- > Kenneth Murchison > Systems Programmer > Project Cyrus Developer/Maintainer > Carnegie Mellon University Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. From murch at andrew.cmu.edu Wed Jun 11 12:03:53 2008 From: murch at andrew.cmu.edu (Ken Murchison) Date: Wed, 11 Jun 2008 12:03:53 -0400 Subject: bug in the proxy module ... In-Reply-To: References: <484D7A63.5060305@andrew.cmu.edu> Message-ID: <484FF769.3060505@andrew.cmu.edu> Your solution looks POP3 specific. As Wes states, I think we need a different methodology. Brasseur Valery wrote: > Well, I would go for : > > while (c == sizeof(buf) && ( buf[sizeof(buf)-1] != '\n' > || buf[sizeof(buf)-2] != '\r' > || buf[sizeof(buf)-3] != '.' > || buf[sizeof(buf)-4] != '\n') > ) > > as I think that checking for '\n' is no enought. > >> -----Message d'origine----- >> De : Ken Murchison [mailto:murch at andrew.cmu.edu] >> Envoy? : lundi 9 juin 2008 20:46 >> ? : Brasseur Valery >> Cc : cyrus-devel at lists.andrew.cmu.edu >> Objet : Re: bug in the proxy module ... >> >> I haven't run into this, but you can try changing the while clause to: >> >> while (c == sizeof(buf) && buf[sizeof(buf)-1] != '\n') >> >> This is completely untested and may have unintended side-effects. >> >> >> Brasseur Valery wrote: >>> Hi, >>> >>> I am using cyrus 2.3.11 in a murder setup... from time to time have >> got an hang from the pop3 proxyd ... >>> I nail it donw to the following portion of code : >>> in imap/proxy.c near line 266 : >>> >>> if (pout) { >>> const char *err; >>> char buf[4096]; >>> int c; >>> >>> do { >>> c = prot_read(pin, buf, sizeof(buf)); >>> >>> if (c == 0 || c < 0) break; >>> prot_write(pout, buf, c); >>> } while (c == sizeof(buf)); >>> >>> if ((err = prot_error(pin)) != NULL) { >>> >>> from time to time, the prot_read return exactly 4096 bytes, but it's >> the end of the message... >>> so backend seat and wait for next command, and proxy seat and wait >> for the next buffer ... >>> forever ! >>> >>> for me it's seems that the condition " c == sizeof(buf)" is not >> enough in that case. >>> >>> >>> have someone else already encoutered this ? >>> >>> >>> thanks >>> valery >>> >>> >>> >>> >>> Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? >> l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? >> par le secret professionnel. Si vous recevez ce message par erreur, >> merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. >> L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la >> responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au >> contenu de ce message. Bien que les meilleurs efforts soient faits pour >> maintenir cette transmission exempte de tout virus, l'exp?diteur ne >> donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre >> recherch?e pour tout dommage r?sultant d'un virus transmis. >>> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and destroy >> it. As its integrity cannot be secured on the Internet, the Atos Origin >> group liability cannot be triggered for the message content. Although >> the sender endeavours to maintain a computer virus-free network, the >> sender does not warrant that this transmission is virus-free and will >> not be liable for any damages resulting from any virus transmitted. >>> >> >> -- >> Kenneth Murchison >> Systems Programmer >> Project Cyrus Developer/Maintainer >> Carnegie Mellon University > > > > Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. > > -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From wes at umich.edu Wed Jun 11 15:46:49 2008 From: wes at umich.edu (Wesley Craig) Date: Wed, 11 Jun 2008 15:46:49 -0400 Subject: bug in the proxy module ... In-Reply-To: <484E8AAB.6000305@andrew.cmu.edu> References: <4B9DAB02-1117-4349-AD5C-38E4278AABE7@umich.edu> <484E8AAB.6000305@andrew.cmu.edu> Message-ID: <21FEDCA5-428A-4DDD-936B-F428731ABEC8@umich.edu> On 10 Jun 2008, at 10:07, Ken Murchison wrote: > Any suggestions? I'm off thinking about other things at the moment. The comment associated with the change is: make sure we send all available data, not just one buffer full. this solves a pipelining problem where a response to a command run on a proxy could be output in the middle of a response to a command run on a backend Both versions call prot_select() once. The old code The new code (attempts) to copy input to output until end of input, but since it's only called prot_select() once, that's a problem. There are a couple of possibilities, perhaps you're more familiar with prot and it's byzantine usage, but here's my analysis: 1) Instead of looping on the size of the read, we loop until prot_read() returns == 0 or < 0. This assumes that pin isn't set to allow blocking. I don't like this solution, since I'm not terribly interested in an exhaustive analysis of every possible pin that proxy_check_input() might get. Maybe you know something I don't, tho. 2) Introduce prot_select() into the read/write loop. This will allow you to know that there's still input available really without blocking. Of course, if it's a very large block of data, you might not see the next block, return control to the calling function, and get the same pipelining problem mentioned in the CVS log above. Assuming you're not worried about that scenario, it's a good solution because it introduces the idea that output from the backend server is handled prior to input from the client. 3) Continuing on the precedence idea above, split the loop handling so that backend output is always handled first. Also, always return control to the caller if you ever have backend output. This way, you'll only ever take input from the client if the backend isn't sending anything. I doubt this solves the race mentioned in (2), either tho. 4) Restructure the routines calling proxy_check_input to know the structure of the commands being sent and the corresponding responses. This is the surest way to fix the above problem, i.e., don't let the proxy server respond to a command until the response to the command sent by the backend is done. Of course, tho is a huge pain, probably involving a ton of additional code. :wes From brong at fastmail.fm Wed Jun 18 00:00:15 2008 From: brong at fastmail.fm (Bron Gondwana) Date: Wed, 18 Jun 2008 14:00:15 +1000 Subject: Linux kernel bug AMD64 - affects skiplists Message-ID: <20080618040015.GA6017@brong.net> I promised I'd have something to say about skiplists soon! (hi Rudy - hope you had a good time off, leaving me here to figure this out _all_by_myself_ ;) ) There's a bug in the linux kernel for amd64 builds only that breaks some skiplist files. Specifically, checkpointing a seen file with a long (greater than page size) list of seen data will cause corruption where it crosses the page break. The last 16-24 bytes will of the page will be NULLed out. You can read more about it in all its gory detail here: http://lkml.org/lkml/2008/6/17/9 Thanks Linus for the prompt (at least partial) fix. If you are running one of those kernels now, I recommend you either change the kernel version, or apply the patch Linus posted. I was going to suggest a little "magic" patch, but I've been unable to actually make it work in testing, so I won't do it! Bron. From schlupp-cyrus at balda7-3.de Thu Jun 19 07:08:31 2008 From: schlupp-cyrus at balda7-3.de (Sebastian Langenhorst) Date: Thu, 19 Jun 2008 13:08:31 +0200 Subject: Cyrus IMAPd 2.3.12p2 - Unknown code 54? Message-ID: <879314533.20080619130831@rfc2549.org> Hi! Since using version 2.3.12p2 imapd in a murder-environment returns "Unknown code 54"-messages.. Here's sample: S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID MUPDATE=mupdate://mupdate/ STARTTLS AUTH=PLAIN AUTH=GSSAPI SASL-IR] mail.test.tld Cyrus IMAP Murder v2.3.12p2 server ready C: E00001 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID MUPDATE=mupdate://mupdate/ STARTTLS AUTH=PLAIN AUTH=GSSAPI SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH S: E00001 OK Unknown code 54 C: B00002 Login "foo" "bar" S: B00002 OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID MUPDATE=mupdate://mupdate/ LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH] User logged in C: N00003 LSUB "" "*" C: O00004 STATUS "INBOX" (UNSEEN RECENT MESSAGES UIDVALIDITY UIDNEXT) S: * LSUB .... S: N00003 OK Unknown code 54 (0.000 secs 0 calls) S: * STATUS INBOX (MESSAGES 70 RECENT 0 UIDNEXT 102 UIDVALIDITY 1208205174 UNSEEN 0) S: O00004 OK Unknown code 54 C: F00009 SELECT "INBOX" S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] S: * 70 EXISTS S: * 0 RECENT S: * OK [UIDVALIDITY 1208205174] S: * OK [UIDNEXT 102] S: * OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox S: * NO [ALERT] Unknown code 45 S: * OK [URLMECH INTERNAL] S: F00009 OK [READ-WRITE] Unknown code 54 C: U00010 FETCH 1:70 (UID FLAGS) .. As you can see there's an "unknown code 54" nearly next to every "OK" - is that correct? Never saw that at 2.3.11... I grep'd already the source, but couldn't find anything suspicious (whereas i'm not really deft with the code) Regards, Sebastian From wes at umich.edu Thu Jun 19 11:42:15 2008 From: wes at umich.edu (Wesley Craig) Date: Thu, 19 Jun 2008 16:42:15 +0100 Subject: Cyrus IMAPd 2.3.12p2 - Unknown code 54? In-Reply-To: <879314533.20080619130831@rfc2549.org> References: <879314533.20080619130831@rfc2549.org> Message-ID: <3F00475E-C36E-4BCC-8E41-97141A0EF2FF@umich.edu> On 19 Jun 2008, at 12:08, Sebastian Langenhorst wrote: > C: E00001 CAPABILITY > S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID MUPDATE=mupdate:// > mupdate/ STARTTLS AUTH=PLAIN AUTH=GSSAPI SASL-IR ACL RIGHTS=kxte > QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT > CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT > THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH > S: E00001 OK Unknown code 54 Examining .../imap/imapd.c cmd_capability(), you see that this message is produced with this line: prot_printf(imapd_out, "\r\n%s OK %s\r\n", tag, error_message(IMAP_OK_COMPLETED)); The "Unknown code 54" is returned by error_message (IMAP_OK_COMPLETED). IMAP_OK_COMPLETED is "defined" in .../imap/ imap_err.et, which ought to be processed during build time to produce .../imap/imap_err.c and imap_err.h. These .et files are intended to be used as part of the com_err package. configure.ac attempts to use the com_err supplied with the system, if there is one. Did you build Cyrus IMAPd on this platform? Please examine the configure log, to see where it's getting com_err et al. :wes