Re: user_deny.db, very high load and Apple-Spotlight
On Friday 15 October 2010 11:47:15 Jeroen van Meeuwen (Kolab Systems) wrote: > Ralf Haferkamp wrote: > > On Thursday 14 October 2010 13:30:22 Marc Patermann wrote: > > > Hi, > > > > > Mark Heisterkamp schrieb am 12.04.2010 09:03 Uhr: [..] > > > > > > I created user_deny.db with touch to make the one error message go > > > away. Now I have lots of "fetching ..." messages in the log > > > (2.3.16). > > > > > > Is there anything to do about this? > > > > You could either upgrade to 2.4.0 as the user_deny.db code has been > > changed there to only try to open the database once. Or I guess you > > could just backport these two patches to your 2.3.16 release: > > > > http://git.cyrusimap.org/cyrus-imapd/commit/?id=e82c657e2f6a3d304d19 > > d737104 cec4782da15c0 > > http://git.cyrusimap.org/cyrus-imapd/commit/?id=3a755fac0d4b43071774 > > af2a64 6ac4fa51aba8f3 > > Could any of you please submit a bug-report in our Bugzilla? Acutally there is one already :), that's want resulted in the 2.4 change: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3206 > I can then go through the motions of backporting those to the 2.3 > branch if appropriate (e.g. if Bron and/or Ken agree). You may just > get a 2.3.17 out of it. thanks, Ralf -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
On Thursday 14 October 2010 13:30:22 Marc Patermann wrote: > Hi, > > Mark Heisterkamp schrieb am 12.04.2010 09:03 Uhr: [..] > > I think we shouldn't advise 5000 users not to use Spotlight, we > > should deactivate user_deny.db. By the way, what is this database > > really good for? If we want someone not to use cyrus-service we > > deny this person by ldap for example. Kenneth Murchison stated in > > some mail on this list that user_deny.db is used once per login, > > that's definitely not true, it is used every time the client 'uses' > > an IMAP-folder and that can be pretty often! Maybe we can change > > this behaviour by some config? > > > > Is it possible to deactivate fetching user_deny.db-entries by some > > config-option or do we have to patch the sources? > > I have this issue, too. > But there is no Mac involved. It is just Thunderbird on the client > (Win*/Linux) side. > > I created user_deny.db with touch to make the one error message go > away. Now I have lots of "fetching ..." messages in the log (2.3.16). > > Is there anything to do about this? You could either upgrade to 2.4.0 as the user_deny.db code has been changed there to only try to open the database once. Or I guess you could just backport these two patches to your 2.3.16 release: http://git.cyrusimap.org/cyrus-imapd/commit/?id=e82c657e2f6a3d304d19d737104cec4782da15c0 http://git.cyrusimap.org/cyrus-imapd/commit/?id=3a755fac0d4b43071774af2a646ac4fa51aba8f3 regards, Ralf -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus 2.3.14 on opensuse 11.1 x64 and lmtp errors
Am Dienstag 28 September 2010, 13:09:02 schrieb Simon Matter: > >Hi, > > > >reject8bit is "no" : > > reject8bit: no > > I think the following option is not a standard Cyrus option: > > rfc_ignore_8bit: yes > > and this one is wrong, in standard Cyrus it's called "munge8bit": > > munge_8bit: no > > You may check if they really have this name and if your Cyrus version > is patched to make use of those options. Maybe you can consult some > OpenSUSE docs because I think this should be noted there. The openSUSE packages do neither know the rfc_ignore_8bit nor munge_8bit. "munge8bit" which is available since 2.3.6 AFAIK is the correct thing to use. [..] -- Ralf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deferred email with remote protocol error in reply
On Friday 27 October 2006 20:42, Wesley Craig wrote: > On 27 Oct 2006, at 05:08, Libor Pechacek wrote: > >> MAIL FROM:<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >> SIZE=15311 > >> RCPT TO:<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >> DATA > > > > < 250 2.1.0 ok > > < 250 2.1.5 ok > > < 354 go ahead > > > >> . > > > > < 7 lockers > > > > In this case the obvious reason for the error is the "7 lockers" line > > that leaked from BDB. It makes only small harm itself but causes the > > next message to be bounced due to protocol error in case the LMTP > > connection is reused. Workaround to the bounces is simple - > > "lmtp_cache_connection = no" in Postfix's main.cf. > > Here's where this happens in BDB 4.3.29: > > ./lock/lock_deadlock.c-418- *nlockers = 0; > ./lock/lock_deadlock.c-419- return (0); > ./lock/lock_deadlock.c-420- } > ./lock/lock_deadlock.c-421- > ./lock/lock_deadlock.c-422- if (FLD_ISSET(dbenv->verbose, > DB_VERB_DEADLOCK)) > ./lock/lock_deadlock.c:423: __db_msg(dbenv, "%lu > lockers", (u_long)count); > ./lock/lock_deadlock.c-424- > ./lock/lock_deadlock.c-425- count += 20; > ./lock/lock_deadlock.c-426- nentries = (u_int32_t)DB_ALIGN(count, > 32) / 32; > ./lock/lock_deadlock.c-427- > ./lock/lock_deadlock.c-428- /* > > So, first thing is that the message shouldn't be written if this > DB_VERB_DEADLOCK isn't set. Quickly skimming the BDB code, it > doesn't appear that this defaults on. I'm wondering if you have: > > set_verbose db_verb_deadlock > > in your DB_CONFIG file? Once it's on, I don't see a way to turn it > off, other than calling the set_verbose method from within Cyrus. cyrus turns on DB_VERB_DEADLOCK itself. See lib/cyrusdb_berkely.c. It seems that one can turn that off via configure.in before building. But the real problem turned out to be that with BDB 4.3.* they changed the "n lockers" message from __db_err() to __db_msg(). To avoid having __db_msg() messages printed on stdout one needs to install a callback handler with dbenv->set_msgcall() in older versions dbenv->set_errcall() was enough to redirect all messages away from stdout. This problem was BTW fixed with cyrus-imapd-2.2.13. For details see e.g.: https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/lib/cyrusdb_berkeley.c.diff?r1=1.10&r2=1.11 -- Ralf Haferkamp SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg T: +49-911-74053-0 F: +49-911-74053575 - [EMAIL PROTECTED] Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Vacation and non-ASCII characters
On Thu, Feb 27, 2003 at 11:51:13AM -0500, Ken Murchison wrote: > > > Ralf Haferkamp wrote: > > > > Hi, > > > > as the reason string of a vacation command in SIEVE is considered to be in > > UTF-8 in absence of the :mime Parameter (see the Internet Draft) wouldn't it > > be correct, to set the MIME-Version and Content-Type Headers accordingly, > > when sending then vacation response? > > Its been a while since I looked at or worked on this part of the code, > but IIRC, the MIME headers are expected to be included as part of the > :mime response in the Sieve script. In theory (and I've actually tested > it), the response doesn't have to be text, it could be a JPEG or > something, so hardcoding the content as text/plain is not a good idea. That's why the patch only adds the headers in cases where there is no :mime parameter in the vacation statement. This is what the ID states: 3.4. MIME Parameter The ":mime" parameter, if supplied, specifies that the reason string is, in fact, a MIME part, including MIME headers (see section 2.4.2.4 of [SIEVE]). If the optional :mime parameter is not supplied, the reason string is considered to be a UTF-8 string. -- regards, Ralf
Vacation and non-ASCII characters
Hi,
as the reason string of a vacation command in SIEVE is considered to be in
UTF-8 in absence of the :mime Parameter (see the Internet Draft) wouldn't it
be correct, to set the MIME-Version and Content-Type Headers accordingly,
when sending then vacation response?
The attached diff was made against cyrus-imapd 2.1.9 and does exactly this.
Please consinder including it into your cvs.
--
regards,
Ralf Haferkamp
SuSE Linux AG- The Linux Experts -
Deutschherrnstrasse 15-19 http://www.suse.com
D-90429 Nuernberg, GermanyTel: +49-911-74053-0
--- imap/lmtpd.c2003/02/26 08:39:34 1.1
+++ imap/lmtpd.c2003/02/26 10:21:08
@@ -914,6 +914,9 @@
fprintf(sm, "\r\nThis is a MIME-encapsulated message\r\n\r\n");
fprintf(sm, "--%d/%s\r\n", (int) p, config_servername);
} else {
+ fprintf(sm, "MIME-Version: 1.0\r\n");
+ fprintf(sm, "Content-Type: text/plain; charset=utf-8\r\n");
+ fprintf(sm, "Content-Transfer-Encoding: 8bit\r\n");
fprintf(sm, "\r\n");
}
Re: Problems with some MIME messages (cyrus-imapd-2.1.9)
On Thu, Nov 21, 2002 at 04:33:07PM -0500, Lawrence Greenfield wrote: > --On Thursday, November 21, 2002 4:29 PM +0100 Ralf Haferkamp > <[EMAIL PROTECTED]> wrote: > > >Hi, > > > >we encountered problems with some multipart MIME mails. It seems, that > >cyrus-imapd fails to correctly seperate the different parts of mail under > >certain circumstances. This e.g. the case if one MIME part of the mail > >contains a multipart/alternative part, that has a boundary which contains > >the boundary of the enclousing MIME part as a substring. I guess I better > >give an example here: ;) > > This is non-compliant MIME. Well, after taking a look at the MIME RFCs again, I think misinterpreted it. I think you are right, it's broken MIME > We'll review the patch (Stanford also had this issue) but it's not high > priority since it's a cater-to-broken-client issue. Ok, thanks. -- Ralf
Problems with some MIME messages (cyrus-imapd-2.1.9)
Hi,
we encountered problems with some multipart MIME mails. It seems, that
cyrus-imapd fails to correctly seperate the different parts of mail under
certain circumstances. This e.g. the case if one MIME part of the mail
contains a multipart/alternative part, that has a boundary which contains
the boundary of the enclousing MIME part as a substring. I guess I better
give an example here: ;)
Let's say the header contains this:
Received: from localhost (localhost [127.0.0.1])
by * (Postfix on SuSE Linux eMail Server 3.1)
with ESMTP id B580FE2DC
for **; Tue, 19 Nov 2002 10:42:50 +0100 (CET)
Content-Type: multipart/mixed;
boundary="=_9011728==_"
Date: Tue, 19 Nov 2002 10:42:03 +0100
From:
And the first mime part looks like this:
--=_9011728==_
Content-Type: multipart/alternative;
boundary="=_9011728==_.ALT"
--=_9011728==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
...
--=_9011728==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
...
--=_9011728==_.ALT--
And after that follows a second part:
--=_9011728==_
...
--=_9011728==_--
Because the boundary of the enclosed multipart/alternative part contains
the same string as the surrounding boundary (+ the string ".ALT")
cyrus-imapd is not able to correctly parse the mail.
It seems that some versions of Eudora created such boundary strings.
The attached patch should fix this problem. BTW: is this the right list to
send patches to or does there exist a mailinglist better suited for this?
--
Ralf Haferkamp
SuSE Linux AG- The Linux Experts -
Deutschherrnstrasse 15-19 http://www.suse.com
D-90429 Nuernberg, GermanyTel: +49-911-74053-0
--- imap/message.c 2002/11/21 13:07:39 1.1
+++ imap/message.c 2002/11/21 13:11:04
@@ -1699,13 +1699,27 @@
char **boundaries;
int *boundaryct;
{
-int i, len;
-
+int i, len,slen;
+char *end;
+
if (s[0] != '-' || s[1] != '-') return(0);
s+=2;
+slen=0;
+end = strchr(s, '\r');
+if(end){
+slen = end - s;
+ if( ( *(end-1) == '-') && (*(end-2) == '-')){
+ slen -=2 ;
+ }
+}
for (i=0; i < *boundaryct; ++i) {
len = strlen(boundaries[i]);
+ /* s might contain a boundaries[i] as a substring. So use the
+ length of s if it is longer than len */
+ if (slen > len){
+ len=slen;
+ }
if (!strncmp(s, boundaries[i], len)) {
if (s[len] == '-' && s[len+1] == '-') *boundaryct = i;
return(1);
Re: A few emails escaping Sieve
On Fri, Feb 22, 2002 at 01:12:43PM -0500, Ken Murchison wrote:
> > the following about header-names:
> >
> > [..]
> > 2.2. Header Fields
> >
> >Header fields are lines composed of a field name, followed by a colon
> >(":"), followed by a field body, and terminated by CRLF. A field
> >name MUST be composed of printable US-ASCII characters (i.e.,
> >characters that have values between 33 and 126, inclusive), except
> >^^
> >colon. A field body may be composed of any US-ASCII characters,
> > [..]
> >
> > It should be easy to fix lmtpengine.c to match this specification. I'll
> > give it a try.
> Fixed in CVS.
Thanks. I have fixed it for 2.0.16. I can post it to the list, if somebody
needs it.
--
Ralf Haferkamp
SuSE GmbH- The Linux Experts -
Deutschherrnstrasse 15-19 http://www.suse.com
D-90429 Nuernberg, GermanyTel: +49-911-74053-0
Re: A few emails escaping Sieve
On Fri, Feb 22, 2002 at 11:40:04AM -0500, Ken Murchison wrote:
>
>
> Christopher Wong wrote:
> >
> > On Fri, 22 Feb 2002, Christopher Wong wrote:
> > > I am using Cyrus-IMAP 2.0.16 with Sieve enabled, and managing it with
> > > websieve. For this mailing list, I set up the following rule using
> > > websieve (as displayed by the "current rules" page):
> > >
> > > IF 'To' contains 'info-cyrus' OR field: 'CC' contains 'info-cyrus' THEN
> > > File Into 'INBOX.Cyrus-IMAP'
> > >
> > > This rule works most of the time. What puzzles me is that some emails do
> > > not get filtered. That is, instead of getting filed into the Cyrus-IMAP
> > > mailbox, occasional emails get past Sieve and end up in my INBOX. Here is
> > > one recent email that got past it:
> >
> > On second thought, I think I should include the full headers. One of the
> > unfiltered emails' headers follow below. One thing different between the
> > unfiltered emails and other emails on the list is the presence of a
> > Received line prefixed by a ">" coming from the sauter-bc.com domain.
> > Could this be messing up Sieve?
>
> Good catch (I've noticed the same problem, but never spent any time
> tracking it down). I'm almost certain that this is what it is causing
> the problem, ie, lmtpd/sieve choke on this header and never read the
> rest. If I have the time, I'll double check the source.
Since we had the same problems here I took a look at the source code.
It is exactly what You guessed. It happens in the function
fill_cache()/parseheader() in lmtpengine.c:
static int fill_cache(..)
{
/* let's fill that header cache */
for (;;) {
char *name, *body;
int cl, clinit;
if (parseheader(fin, fout, &name, &body) < 0) {
break;
}
[..]
parseheader tries to split a mail header into its contents. It returns a
values less than 0, in case the Header name doesn't start with an Letter
(it checks with isalpha)
> > Does that prefix belong in the headers?
>
> No. I'm pretty certain that if you check RFC[2]822 that this is an
> illegal header. Just like "From" without a colon is illegal.
Yes, that is what I thought, but then I took a look at the RFCs. RFC2822 says
the following about header-names:
[..]
2.2. Header Fields
Header fields are lines composed of a field name, followed by a colon
(":"), followed by a field body, and terminated by CRLF. A field
name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
^^
colon. A field body may be composed of any US-ASCII characters,
[..]
It should be easy to fix lmtpengine.c to match this specification. I'll
give it a try.
--
Ralf Haferkamp
SuSE GmbH- The Linux Experts -
Deutschherrnstrasse 15-19 http://www.suse.com
D-90429 Nuernberg, GermanyTel: +49-911-74053-0
SIEVE: Problems with multi-line strings (reject- and vacation action)
Hi, I encountered some problems using the multi-line string form in vacation- and reject actions of SIEVE scripts. The following (constructed) example should show the problem. E.g. I want to send a vacation reply containing the following lines: snip line1 blah blah . line3 blah blah snip The vacation command using the multi-line form would look like the following. The important part is the dotstuffing: snip require "vacation"; vacation :days 1 text: line1 blah blah .. line3 blah blah . ; snip The script can be correctly transfered to the server using timsieved. The problem is now, that the SIEVE implementation of cyrus-imapd does not send the complete vacation reply. Instead it does just send the first line. Could it be, that internally ( inside lmtpd ? ) the dotstuffing is removed so that lmtpd just gets a single dot and "thinks" the mail is ended? BTW: The same happens with the reject action. All this happens with version 2.0.16 of cyrus-imapd. Is this a bug in my script or somewhere in the software. Any ideas? -- regards, Ralf
How can I use AUTH proxying with timsieved
Hi, I am trying to use AUTH proxying with timsieved. As far as I understand it I have to use at least the PLAIN SASL mechanism to use AUTH proxying. But by default the LOGIN mechanism is used. I am using the managesieve Perl modules to access the server. How can I tell them to use the PLAIN mechanism. Cyrus-imapd version: 2.0.12 BTW: If I use use sasldb for password verification and DIGEST-MD5 for authentication it works well. But I have to use pam for my application so I am stuck with PLAIN authentication, right? -- Regards, Ralf
Bug in SIEVE-implementation?
Hi, The sieve-implementation of cyrus-imapd cannot parse a sequence like this one : [...] if allof ( header :contains ["From", "To"] ["test\\"] ) ^^^ [...] The problem is the escaped backslash at the end of the string. If I put a space between the last backslash and the quote sign (\\ ") it works. So it seems, that sieve recognizes the sequence as an escaped quote sign. Bug or Feature? Note: I do not consider this a big issue. It is just a little annoying -- bye, Ralf
SIEVE question
Hi,
Is it possible to write a SIEVE filterrule that checks all mail headers for
a specific string? Something like:
if header :contains [*] "blahblah"{
discard; ^
}|
|
|___
What do I have do put here to
test _all_ mail headers?
--
regards,
Ralf
