You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(34) |
Aug
(7) |
Sep
(12) |
Oct
(26) |
Nov
(30) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(9) |
Feb
(36) |
Mar
(16) |
Apr
|
May
(6) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(11) |
From: System S. <su...@mi...> - 2008-12-11 17:11:21
|
On 10 Dec 2008 at 7:32, Murray S. Kucherawy wrote: > On Wed, 10 Dec 2008, System Support wrote: > > The error stopped altogether (in any format) after going from Beta2 > > to Beta4 and applying the patch. > > Well, you've got me on that one. I just reviewed the diffs between > Beta2 and Beta4, and there's no code change involving header parsing > at all. Unless this happens again, let's write this off as some sort of installation problem on my part. ...don dhughes (at) microtechniques.com White Plains, NY |
From: Murray S. K. <ms...@se...> - 2008-12-10 15:32:12
|
On Wed, 10 Dec 2008, System Support wrote: > The error stopped altogether (in any format) after going from Beta2 to > Beta4 and applying the patch. Well, you've got me on that one. I just reviewed the diffs between Beta2 and Beta4, and there's no code change involving header parsing at all. |
From: System S. <su...@mi...> - 2008-12-10 14:45:36
|
On 7 Dec 2008 at 19:18, Murray S. Kucherawy wrote: > On Sun, 7 Dec 2008, System Support wrote: > > Nov 26 18:32:32 Falcon dkim-filter[2199]: EC214454AC: can't parse > > From: header > > There haven't been any changes to header parsing code, so I can't > think of why this would start happening as a result of the upgrade. > > Try the attached patch; it does two things: > > 1) Reports which header is actually being selected rather than always > reporting "From:" > > 2) Gives you the value it wasn't able to parse for a user and domain The error stopped altogether (in any format) after going from Beta2 to Beta4 and applying the patch. ...don dhughes (at) microtechniques.com White Plains, NY |
From: Murray S. K. <ms...@se...> - 2008-12-08 23:05:15
|
On Mon, 8 Dec 2008, Chris Behrens wrote: > Looks like that last line should really be: Ah right. Here's the corrected patch. |
From: Chris B. <cbe...@co...> - 2008-12-08 23:00:15
|
On Mon, Dec 08, 2008 at 02:30:53PM -0800, Murray S. Kucherawy wrote: > - syslog(LOG_INFO, "%s: can't parse From: header", > - dfc->mctx_jobid); > + syslog(LOG_INFO, > + "%s: can't parse %s: header value `%s'", > + from->hdr_hdr, from->hdr_val, dfc->mctx_jobid); Looks like that last line should really be: dfc->mctx_jobid, from->hdr_hdr, from->hdr_val); - Chris |
From: Murray S. K. <ms...@se...> - 2008-12-08 22:31:08
|
On Mon, 8 Dec 2008, System Support wrote: >> Try the attached patch; it does two things: > > There was nothing attached. Is this the Dec 7th beta? No, it wasn't in that beta. Sorry for skipping the attachment; it's on this one. |
From: System S. <su...@mi...> - 2008-12-08 22:28:22
|
On 7 Dec 2008 at 19:18, Murray S. Kucherawy wrote: > On Sun, 7 Dec 2008, System Support wrote: > > Nov 26 18:32:32 Falcon dkim-filter[2199]: EC214454AC: can't parse > > From: header > > There haven't been any changes to header parsing code, so I can't > think of why this would start happening as a result of the upgrade. > > Try the attached patch; it does two things: Murry, There was nothing attached. Is this the Dec 7th beta? ...don dhughes (at) microtechniques.com White Plains, NY |
From: Murray S. K. <ms...@se...> - 2008-12-08 03:18:48
|
On Sun, 7 Dec 2008, System Support wrote: > Nov 26 18:32:32 Falcon dkim-filter[2199]: EC214454AC: can't parse > From: header There haven't been any changes to header parsing code, so I can't think of why this would start happening as a result of the upgrade. Try the attached patch; it does two things: 1) Reports which header is actually being selected rather than always reporting "From:" 2) Gives you the value it wasn't able to parse for a user and domain This will appear in the next beta. |
From: System S. <su...@mi...> - 2008-12-07 22:53:18
|
I have started seeing the following error after the last upgrade: Nov 26 18:32:32 Falcon postfix/smtpd[30645]: EC214454AC: client=mailo[127.0.1.10] Nov 26 18:32:32 Falcon postfix/cleanup[30649]: EC214454AC: message- id=<492...@dh...> Nov 26 18:32:32 Falcon dkim-filter[2199]: EC214454AC: can't parse From: header Nov 26 18:32:32 Falcon postfix/qmgr[2611]: EC214454AC: from=<postmaster@MicroTechniques.com>, size=1407, nrcpt=1 (queue active) The one of interest is from dkim-filter -- 'Can't parse From: header' I have not made any other postfix or mail system changes. ...don dhughes (at) microtechniques.com White Plains, NY |
From: Murray S. K. <ms...@se...> - 2008-12-07 20:49:21
|
On Mon, 8 Dec 2008, Hirohisa Yamaguchi wrote: > With 2.8.0.Beta3, I got many errors: > dkim.h:1543: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'dkim_get_arlib' > > including dkim-types.h before dkim.h is needed. I just yanked dkim_get_arlib() out of both dkim.c and dkim.h. The thing for which I needed it isn't happening anymore. |
From: Hirohisa Y. <um...@gm...> - 2008-12-07 17:20:27
|
Hi, With 2.8.0.Beta3, I got many errors: dkim.h:1543: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'dkim_get_arlib' including dkim-types.h before dkim.h is needed. -- end Hirohisa Yamaguchi um...@gm... |
From: Murray S. K. <ms...@se...> - 2008-11-03 19:37:57
|
The first beta release of v2.8.0 of dkim-milter is now available via SourceForge under the "DKIM Milter Pre-Releases" package. Of particular significance in this release is support for using DNSSEC to query for keys and policies, and some knobs that can be adjusted to treat insecure or bogus results in special ways. Big thanks to John Dickinson for supplying the patch and support for it. Please consult the release notes and other package documentation to learn about what's changed. If you have any questions about how to use some of the new code, or if you encounter any problems, please post your questions or remarks here; don't use the SourceForge trackers for beta releases. I'm planning about a two-week beta cycle this time, but can easily extend it if needed. |
From: Murray S. K. <ms...@se...> - 2008-06-06 17:27:49
|
On Fri, 6 Jun 2008, System Support wrote: > 1) This sequence shows 'verification successful' and then 'bad > signature' seems a contradiction. Based on the log entries, you're verifying both DomainKeys and DKIM. It looks like one succeeded while the other did not. I'd have to see a copy of a message which causes this to be more precise. > 2) This seems to indicate that hotpop has a configuration issue. > However, the reject shows a 4xx error. If it is a hotpop error, how do > I report it. The DomainKeys signature you tried to verify wasn't properly added to the arriving message. Unlike DKIM, the position of the DomainKeys header is significant, and they appear to have gotten it wrong. > 3) This just looks like a dice error. How do it report it? I tried e- > mail to pos...@di... to no effect. That's what I would try. I wouldn't know what else to suggest. |
From: System S. <su...@mi...> - 2008-06-06 13:03:25
|
While examining my logs I found the following messages. I have not seen them in the past and I am not sure of their importance: 1) This sequence shows 'verification successful' and then 'bad signature' seems a contradiction. Jun 5 21:47:26 Falcon postfix/smtpd[11797]: AEFF8CD61A: client=yw-out- 2324.google.com[74.125.46.28] Jun 5 21:47:26 Falcon postfix/cleanup[11801]: AEFF8CD61A: message- id=<484...@dh...> Jun 5 21:47:26 Falcon dkim-filter[3409]: AEFF8CD61A: dk_eoh() returned status 1 Jun 5 21:47:26 Falcon dkim-filter[3409]: AEFF8CD61A DKIM verification successful Jun 5 21:47:26 Falcon dkim-filter[3409]: AEFF8CD61A SSL error:04077068:rsa routines:RSA_verify:bad signature Jun 5 21:47:26 Falcon postfix/qmgr[3612]: AEFF8CD61A: from=<wpnyus+caf_=forwarded=mic...@gm...>, size=6896, nrcpt=1 (queue active) Jun 5 21:47:27 Falcon postfix/pipe[11802]: AEFF8CD61A: to=<for...@mi...>, relay=spamfilter, delay=1.2, delays=0.67/0.01/0/0.53, dsn=2.0.0, status=sent (delivered via spamfilter service) Jun 5 21:47:27 Falcon postfix/qmgr[3612]: AEFF8CD61A: removed 2) This seems to indicate that hotpop has a configuration issue. However, the reject shows a 4xx error. If it is a hotpop error, how do I report it. Jun 5 13:42:06 Falcon postfix/smtpd[5323]: 44522CD61A: client=smtp- out.hotpop.com[38.113.3.61] Jun 5 13:42:06 Falcon postfix/cleanup[5337]: 44522CD61A: message- id=<f1a...@ma.... au> Jun 5 13:42:07 Falcon dkim-filter[3409]: 44522CD61A dk_eom() returned status 5: no sender header found below signature Jun 5 13:42:07 Falcon dkim-filter[3409]: 44522CD61A: key retrieval failed Jun 5 13:42:07 Falcon postfix/cleanup[5337]: 44522CD61A: milter- reject: END-OF-MESSAGE from smtp-out.hotpop.com[38.113.3.61]: 4.7.1 Service unavailable - try again later; from=<qwc...@su...> to=<for...@mi...> proto=ESMTP helo=<smtp-out.hotpop.com> 3) This just looks like a dice error. How do it report it? I tried e- mail to pos...@di... to no effect. Jun 6 03:57:51 Falcon postfix/smtpd[16807]: 6331ECD61A: client=mailbox3.dice.com[65.198.147.3] Jun 6 03:57:54 Falcon postfix/cleanup[16818]: 6331ECD61A: message- id=<200...@vi...> Jun 6 03:57:55 Falcon dkim-filter[3409]: 6331ECD61A: bad signature data Jun 6 03:57:55 Falcon postfix/cleanup[16818]: 6331ECD61A: milter- reject: END-OF-MESSAGE from mailbox3.dice.com[65.198.147.3]: 5.7.0 bad DKIM signature data; from=<jo...@di...> to=<jo...@mi...> proto=ESMTP helo=<mailbox3.dice.com> ...don support (at) microtechniques.com |
From: Murray S. K. <ms...@se...> - 2008-05-29 20:17:03
|
On Thu, 29 May 2008, Graham Murray wrote: > gcc -o dkim-filter -lpthread config.o dkim-ar.o dkim-arf.o dkim-db.o dkim-filter.o stats.o test.o util.o -lmilter /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdk/libdk.a /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/libdkim.a /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libsm/libsm.a -ldb -lresolv -lcrypt -lnsl -ldl -ltre -lssl -lcrypto > /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/libdkim.a(dkim-test.o): In function `dkim_test_key': > /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/dkim-test.c:309: undefined reference to `dkim_process_set' > /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/dkim-test.c:319: undefined reference to `dkim_siglist_setup' > collect2: ld returned 1 exit status The attached patch fixes it. Looks like there was one change I hadn't commited to our CVS repository before rolling that release. Sorry about that. |
From: Graham M. <gr...@gm...> - 2008-05-29 19:25:43
|
Attempting to build dkim-milter-2.6.0.Beta1 gcc -o dkim-filter -lpthread config.o dkim-ar.o dkim-arf.o dkim-db.o dkim-filter.o stats.o test.o util.o -lmilter /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdk/libdk.a /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/libdkim.a /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libsm/libsm.a -ldb -lresolv -lcrypt -lnsl -ldl -ltre -lssl -lcrypto /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/libdkim.a(dkim-test.o): In function `dkim_test_key': /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/dkim-test.c:309: undefined reference to `dkim_process_set' /home/graham/dkim-milter-2.6.0.Beta1/obj.Linux.2.6.25-gentoo-r4.i686/libdkim/dkim-test.c:319: undefined reference to `dkim_siglist_setup' collect2: ld returned 1 exit status |
From: Murray S. K. <ms...@se...> - 2008-05-29 18:06:59
|
On Wed, 28 May 2008, System Support wrote: >> As I understand it, your mail arrives thus: >> >> From: X >> To: Y >> Resent-To: Z >> [other headers] > > Yes > >> >> Who are the SMTP sender and recipient(s)? > > I believe that they are postmaster (at) microtechniques.com and > mboxreport (at) microtechniuqes.com OK, so since it keys on the envelope, let's try matching that. If you set: DontSignMailTo mboxreport@* ...does it do what you need? |
From: System S. <su...@mi...> - 2008-05-28 19:28:53
|
On 28 May 2008 at 11:09, Murray S. Kucherawy wrote: > So the forwarding actually happens in the mail client? That's odd, and so > now I'm a little confused. Hopefully you can clarify for me. If so, > maybe we can salvage the idea. A little more information may help. The mail client has a filter that inspects the X-Spam headers + other stuff and puts matching mail in a 'potential spam' folder. Every now and again I review the folder. particually annoying stuff I tag and it is forwarded on to the the spam lists + my local bayesian scanner + the spamassassin learn function. > > As I understand it, your mail arrives thus: > > From: X > To: Y > Resent-To: Z > [other headers] Yes > > Who are the SMTP sender and recipient(s)? I believe that they are postmaster (at) microtechniques.com and mboxreport (at) microtechniuqes.com Originally there were multiple recipients, but I changed the script to send separate e-mails with only one recipient each. Here are the headers from a sample message (addresses mangled slightly) X-PM-Identity: Forward Resent-from: "postmaster" <postmaster @ microtechniques.com> Resent-to: mboxreport @ microtechniques.com Resent-date: Wed, 28 May 2008 15:02:58 -0400 Return-Path: <dhughes @ MicroTechniques.com> X-Original-To: dhughes @ microtechniques.com Delivered-To: dhughes @ microtechniques.com Received: from 127.0.0.1 (localhost [127.0.0.1]) by mail.MicroTechniques.com (Falcon mail server) with SMTP id 379CECD4D3 for <dhughes @ microtechniques.com>; Wed, 28 May 2008 15:01:55 - 0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on Falcon.Net1.MicroTechniques.com X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_MID,TO_MALFORMED autolearn=ham version=3.2.3 Received: from mailo.MicroTechniques.com (Plover.Net1.MicroTechniques.com [10.168.xx.xx]) by maili.MicroTechniques.com (Falcon mail server) with ESMTP id 52D1DCD98F for <dhughes @ microtechniques.com>; Wed, 28 May 2008 15:01:54 - 0400 (EDT) Received: from [10.168.xx.xx] (xx.Microtechniques.com [10.168.xx.xx]) by mailo.MicroTechniques.com (Falcon mail server) with ESMTP id 36D03CD4D3 for <dhughes @ microtechniques.com>; Wed, 28 May 2008 15:01:54 - 0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.6.0.Beta0 mailo.MicroTechniques.com 36D03CD4D3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=MicroTechniques.com; s=MT_email; t=1212001314; bh=mHeouLbIxahfAMD4g/vM2Tc3QfVjF34kUAp1EV x85ZM=; h=Resent-from:Resent-to:Resent-date:From:To:Subject: MIME-Version:Content-type:Content-transfer-encoding:Date: Resent-Message-Id; b=iNPgMT10LOGaxg6F7Xr14wbevL+F8vL5MUG7gSVXsxdGo PdGHf4LCbMo5bXfb2vXG723tFzhVRG+qm7ZH0+epd9g3tgdbs0tN/mTTzJCqgO78bRx EADizq2Vnly5K0ZGzs7/bl/5xQnfoKJPkqaP6werCVHa4Lrdq7PZ4oiaeXw= X-cs: R X-CS-Version: 1.0 From: Don Hughes <dhughes @ microtechniques.com> X-RS-ID: <Default> X-RS-Flags: 0,0,1,1,0,0,0 X-RS-Sigset: -1 To: TestList @ maili.MicroTechniques.com Subject: Budget MIME-Version: 1.0 Date: Tue, 20 May 2008 10:04:57 -0500 Resent-Message-Id: <200...@ma...> X-Antivirus: AVG for E-mail 8.0.100 [269.24.1/1469] ...don support (at) microtechniques.com |
From: Murray S. K. <ms...@se...> - 2008-05-28 18:10:11
|
On Wed, 28 May 2008, System Support wrote: >> What's adding the Resent-To: header here? Is it already on the message >> when it arrives, or is it postfix adding it as a result of an alias or >> forward file? > > Already there - added by the mail client. So the forwarding actually happens in the mail client? That's odd, and so now I'm a little confused. Hopefully you can clarify for me. If so, maybe we can salvage the idea. As I understand it, your mail arrives thus: From: X To: Y Resent-To: Z [other headers] Who are the SMTP sender and recipient(s)? |
From: Murray S. K. <ms...@se...> - 2008-05-28 16:40:06
|
Please restrict feedback about Beta releases to the dkim-milter-beta list. On Wed, 28 May 2008, System Support wrote: > 1) The sample .config file does not have the new options, although the > help file does. Fixed; will appear in the next Beta. > 3) DontSignMailTo does not seem to be working as hoped. > > have something like: > DontSignMailTo re...@sp...,pos...@ot... > > As requested, mail is Forwarded to those sites, and looking at the > headers what needs to be matched is the 'Resent-to' header. There was a bug in the way the recipient list was walked when looking for matches. A fix for this appears in the next Beta (later today; I typically do a Beta release each day if there's been a change since the previous one). However, I just saw that in a passing review of the relevant code. In fact, your requirement may be more difficult than I thought to deal with. The milter component of both postfix and sendmail operates when the mail arrives via SMTP. If mail lands on your machine addressed to X but is automatically forwarded to Y, the filter never sees the forwarding operation; it only sees X as the recipient. This is because the filter sees exactly the SMTP conversation with the client injecting the message; aliasing and forwarding happen after that and are not part of milter. Thus, if that's the order in which things are happening on your system, then there's not much the filter can do to solve this problem because DontSignMailTo can't work here because the filter is never told that Y is the ultimate recipient. What's adding the Resent-To: header here? Is it already on the message when it arrives, or is it postfix adding it as a result of an alias or .forward file? Matching DontSignMailTo on a header field instead of an envelope recipient is more challenging because parsing those headers looking for matches can be quite a chore; there can be more than one such header, and there can be more than one address per header, and isolating them for matching can be a challenge in itself. |
From: Murray S. K. <ms...@se...> - 2008-03-17 18:03:38
|
On Fri, 14 Mar 2008, ca3...@re... wrote: > This is using dkim-milter-2.5.0 release this time. (Not the beta.) I > got two failure messages but only one core file. I have the emails if > you need them. Yes, please send them along. If this is still happening with 2.5.0 then I'd like to get a handle on the problem since I was planning to post 2.5.1 early this week. Thanks for capturing the trace! Unfortunately it's a little confusing (never a good sign); it suggests that thread #2 raised the signal causing the crash after being asked to free() a bad pointer, but the pointer it's trying to free was allocated earlier in the same thread so there's no indication of why it should be bad. That suggests general heap corruption which can be tough to track down. -MSK |
From: <ca3...@re...> - 2008-03-15 03:44:16
|
On Sun, 2 Mar 2008, Murray S. Kucherawy wrote: >>> I have an error with dkim-milter-2.5.0.Beta10. This is verifying an email >>> from americangreetings.com similar to one a couple of weeks ago. It has >>> h= headers that don't appear in the message. > > I just had americangreetings.com send me mail to a home machine running > Beta10. It had the extra headers in h= as well, but there was no crash or > other error on my end. The message verified successfully. > > Can you capture the problem, or a stack trace, or something like that? > Sorry to take so long to get back to you. I needed to learn about gdb, core files etc.! Attached is the output of gdb "thread apply all bt full" using the core file. Let me know if I should use different gdb options. This is using dkim-milter-2.5.0 release this time. (Not the beta.) I got two failure messages but only one core file. I have the emails if you need them. Mar 14 20:09:49 mostly sendmail[6739]: m2F09gVp006739: milter_sys_read(dkim-filter): cmd read returned 0, expecting 5 Mar 14 20:09:49 mostly sendmail[6739]: m2F09gVp006739: Milter (dkim-filter): to error state Mar 14 20:09:49 mostly sendmail[6738]: m2F09gco006738: milter_sys_read(dkim-filter): cmd read returned 0, expecting 5 Mar 14 20:09:49 mostly sendmail[6738]: m2F09gco006738: Milter (dkim-filter): to error state Thanks, CA |
From: Murray S. K. <ms...@se...> - 2008-03-05 18:00:29
|
On Thu, 6 Mar 2008, Hirohisa Yamaguchi wrote: > I appended confINCDIRS' to use OpenSSL installed via FreeBSD ports, and > it made the older dkim.h included. > > To avoid this, I would suggest placing `-I../libdkim/ ' before > confINCDIRS defined in site.config.m4. Done for next release. Thanks! |
From: Hirohisa Y. <um...@gm...> - 2008-03-05 17:10:40
|
Hi, In a box which have dkim-milter 2.4.[34] installed, I got a build error following: | cc -g -I. -I../../include -I/usr/local/include -I../libdkim/ -DXP_MT -c dkim-filter.c | dkim-filter.c: In function `dkimf_config_setlib': | dkim-filter.c:2454: error: `DKIM_LIBFLAGS_FIXCRLF' undeclared (first use in this function) | dkim-filter.c:2454: error: (Each undeclared identifier is reported only once | dkim-filter.c:2454: error: for each function it appears in.) | dkim-filter.c: In function `mlfi_eom': | dkim-filter.c:5549: error: too few arguments to function `dkim_policy' | dkim-filter.c:5556: error: `DKIM_POLICY_DISCARDABLE' undeclared (first use in this function) | dkim-filter.c:5558: error: `DKIM_PRESULT_AUTHOR' undeclared (first use in this function) | dkim-filter.c:5559: error: `DKIM_PRESULT_PARENT' undeclared (first use in this function) | *** Error code 1 I appended confINCDIRS' to use OpenSSL installed via FreeBSD ports, and it made the older dkim.h included. To avoid this, I would suggest placing `-I../libdkim/ ' before confINCDIRS defined in site.config.m4. -- end Hirohisa Yamaguchi um...@gm... |
From: やまきゅう <um...@gm...> - 2008-03-05 16:51:50
|
At Mon, 3 Mar 2008 15:10:22 -0800 (PST), Murray S. Kucherawy wrote: > It appears the versions of libdb you're testing simply assume that mutexes > aren't available on 64-bit FreeBSD, so attempts to tell libdb to enable > its threading support caused EINVAL to be returned. (The error they > return is EINVAL with a descriptive string of "architecture lacks fast > mutexes: applications cannot be threaded") > I've tested this against 3.3.11 and 4.0.14 and the fix works. Essentialy > I don't use the threading facilities in libdb at all and just wrap the > calls in a mutex. This is undoubtedly not as fast, but probably not > measurably so for now. If it is indeed shown to be a performance > degradation, we may simply have to declare that some versions of DB can't > be used on 64-bit FreeBSD because we'll want to use the threading > faciliities in libdb, and another (more extensive) patch will be needed > to make more thorough use of the DB environment stuff. I understand the concept of workaround, and Beta11 loos working. -- end やまきゅう um...@gm... |