[Dovecot] old mails
I just got a 6 months old mail to this list and wondered for a while why it happened. Looks like the old dovecot.org was rebooted and Postfix went up and started sending queued mails. So just ignore if you got those. signature.asc Description: This is a digitally signed message part
[Dovecot] Updated v1.1 and summer plans
Webmail.us will be sponsoring my Dovecot development for this summer. Other companies are also welcome to participate in the costs. Participation gets you: - listed in Credits in www.dovecot.org - listed in AUTHORS file - you can tell me how you want to use the feature and I'll make sure that it supports it (within reasonable limits) For already implemented v1.1 features, see http://www.dovecot.org/ list/dovecot/2007-April/021974.html Some of those features require some more testing (new SORT and THREAD code especially) and a bit of fixes to mailbox list indexes. Otherwise I think it's working pretty well already, I've been using it for a long time for my own mails. Upcoming v1.1 features, more or less implemented in this order: - Index file optimizations: http://www.dovecot.org/list/dovecot/ 2007-May/022591.html - Less indexing for POP3 users (both in pop3 and in deliver) - Replace Squat FTS indexes with my new design - Configurable mail_log plugin - Limit number of connections for a user - A combined LIST + STATUS command (or possibly NOTIFY extension? http://tools.ietf.org/html/draft-gulbrandsen-imap-notify-03) - Fully supported shared mailboxes and IMAP ACL extension: http:// www.dovecot.org/list/dovecot/2007-April/021624.html - Remote (shared) mailboxes. Automatic proxying, but possibly also support for MAILBOX-REFERRALS extension if it's not much extra trouble (few clients support it, so probably not worth the trouble unless it can be done in a couple of hours) - Remove unused keywords from mailboxes - Some other small things Upcoming v1.1/v1.2/v2.0 features (planned to be implemented at the end of the summer): - virtual mailboxes: http://www.dovecot.org/list/dovecot/2007-May/ 022828.html - dbox redesign: http://www.dovecot.org/list/dovecot/2007-May/ 022602.html Implementing the above features will keep me busy for most of the summer, but there have also been requests for replication support (http://www.dovecot.org/list/dovecot/2007-May/022792.html). I'm interested in implementing it as well, but unfortunately it looks like I don't have time for it at least for the next 3 months or so. There's already at least one company that's willing to pay for replication, but if you're also interested please let me know. Perhaps someone else could implement it instead (if you're interested, please let me know), or if not it'll just have to wait until I have time for it. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] SPAM: Re: 1.1beta9 'make' fails on osx/Tiger
On Nov 28, 2007, at 5:51 PM, snowcrash wrote: p.s. The folks at AT&T also recommend that "you" use the newer version of gcc than the older-hacked-to-get-something-for-Tiger version of the Apple Leopard version they (AT&T) are providing -- it is further down the page where they provide links. just looked at the page & have no idea what you're referring to ... can you quote? thx. http://r.research.att.com/tools/ It begins with Building a universal compiler Note: This section is now becoming obsolete given Apple's gcc 42 branch, but it is kept here until we have more definite information on Apple's Fortran support. . .. ... ... skipping down to ... ... .. . get gcc sources This is obviuos, you clearly need gcc sources. One way to get them is via svn, for example: svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch gcc-4.2 Leopard has svn built in, there are open source clients available for Tiger. If you do not like using svn to get your stuff, just hit the main gcc.gnu.org site and follow the links to grab the gzipped file. Since this is really drifting away from Dovecot, the rest of the folks on the list might prefer to take the correspondence off the list. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger
> p.s. The folks at AT&T also recommend that "you" use the newer version > of gcc than the older-hacked-to-get-something-for-Tiger version of the > Apple Leopard version they (AT&T) are providing -- it is further down > the page where they provide links. just looked at the page & have no idea what you're referring to ... can you quote? thx.
Re: [Dovecot] autogen.sh fails -> "required file `./config.rpath' not found"
fair nuf. my point simply is, the check should make sense --- or at least be documented. and the email was just an fyi. personally, i can work around it ... cheers.
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger
On Nov 28, 2007, at 1:39 PM, [EMAIL PROTECTED] wrote: -- Message: 7 Date: Wed, 28 Nov 2007 10:38:19 -0800 From: snowcrash <[EMAIL PROTECTED]> Subject: Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger To: "Jerry Yeager" <[EMAIL PROTECTED]> Cc: dovecot@dovecot.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 (stuff cut out) i'd gather tss would like to know about issues. (it shouldn't be terribly surprising for a projects' beta release to at least be _tried_ with _other_ projects' beta releases ...) cheers. That is usually a good idea, especially if you mention that you are using non standard stuff so that folks who are not aware of that can then get a better understanding of the issues. Or for the elucidation of the folks that are following the list trying to decide what efforts they will have to undertake to make the switch. p.s. The folks at AT&T also recommend that "you" use the newer version of gcc than the older-hacked-to-get-something-for-Tiger version of the Apple Leopard version they (AT&T) are providing -- it is further down the page where they provide links. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] SPAM: Re: spf record
on 11/28/2007 10:49 AM jflowers spake the following: I may be sorry I brought this up. There's nothing wrong with your TXT record. This server acts as a virus/spam processor for mail relayed from a legacy server (for historical reasons). It filters with MailScanner/SpamAssassin. Looking through the SpamAssassin debug code, it checks my relay as the 'Envelope-from' and fails on -all. Although the information is there, the SpamAssassin plugin isn't sophisticated enough to trace it back to the originating server. Look at trusted_relays in spamassassin. http://wiki.apache.org/spamassassin/TrustedRelays -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't
Re: [Dovecot] spf record
Hello, M. Fioretti pisze: On Wed, Nov 28, 2007 10:14:31 AM -0800, Marc Perkel ([EMAIL PROTECTED]) wrote: > >Everyone has different opinions on the usefulness of SPF, but the > >reality of it is, DomainKeys solves the entire problem. SPF > >doesn't. > > I second that. I've wasted a lot of time with SPF and it's useless. Maybe. Or maybe, more exactly, is useless to use, but it's necessary to have. The reality today is that if you manage a mail server you simply have to get your SPF right, no matter what you do or do not with SPF of _incoming_ messages. What the message that starts the thread means is that, if anybody with a @dovecot.org address (or any other domain address with the same SPF status) sends a CV to some dream company he'd like to work for, but the address he wrote is an hotmail one (or is forwarded to an hotmail one) that company will never see his CV and hire somebody else. And there are too many people with an Hotmail account (and you not knowing they have an hotmail account) which you or your users may NEED to contact to ignore such cases. I have heard the same arguments thousand times on various MTA-related lists. I thought this list was dedicated to dovecot and so maybe we could drop this thread? It does not seem dovecot-related and the thread - as usual in such a case - is generating quite a heavy traffic. Best regards, Zbigniew Szalbot Marco
Re: [Dovecot] spf record
On Wed, Nov 28, 2007 10:14:31 AM -0800, Marc Perkel ([EMAIL PROTECTED]) wrote: > >Everyone has different opinions on the usefulness of SPF, but the > >reality of it is, DomainKeys solves the entire problem. SPF > >doesn't. > > I second that. I've wasted a lot of time with SPF and it's useless. Maybe. Or maybe, more exactly, is useless to use, but it's necessary to have. The reality today is that if you manage a mail server you simply have to get your SPF right, no matter what you do or do not with SPF of _incoming_ messages. What the message that starts the thread means is that, if anybody with a @dovecot.org address (or any other domain address with the same SPF status) sends a CV to some dream company he'd like to work for, but the address he wrote is an hotmail one (or is forwarded to an hotmail one) that company will never see his CV and hire somebody else. And there are too many people with an Hotmail account (and you not knowing they have an hotmail account) which you or your users may NEED to contact to ignore such cases. Marco -- Help *everybody* love Free Standards and Free Software http://digifreedom.net/
Re: [Dovecot] autogen.sh fails -> "required file `./config.rpath' not found"
On 2007-11-28 10:29:26 -0800, snowcrash wrote: > > the real solution would be to copy the config.rpath [1] from your distro > > into the source dir. this requires the gettext devel files to be > > installed. > > i'm not using nls/gettext. afaict, it's not even mentioned (in > configure, doc, INSTALL, etc) as an option. then, gettext shouldn't > be a requirement (even though it's installed on my system ...). > > the point is, the check for the file is there, but the file is not > included. autogen.sh > *would* copy it if i spec'd the location of my gettext in > /usr/local/share (odd that the check wouldn't be for 'standard' > locations ... ), but, again, why's it asked for? > > > now the question is when using the 1.1b9 tarball. > > why do you run autogen.sh at all? > > i'm not using the tarball -- rather > > hg clone -r1.1.beta9 http://hg.dovecot.org/dovecot > > instructions, of course, are: > > "If you got Dovecot from Mercurial, for instance with > > > ---%<- > hg clone http://hg.dovecot.org/dovecot/ > ---%<- > > you will first need to run './autogen.sh' to generate the 'configure' > script and some other files." it wasnt me who brought that shit into the autotools. but i would not hackaround with empty files in that area. just my 2 cents, darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] spf record
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt wrote: >> But as a matter of fact, I got corrected. The major problem with even >> scoring is that the only things spammers have to do (and they really do >> it!) is to register some new domain, enter valid SPF records for it and >> then their scoring might even improve. > > DKIM and domainkeys are really no better in that respect. Spammers > typically do not go through that much effort though. yes, IMHO this entire sender verification thing (whatever that may be) is quite useless when it comes to prevent spamming but is quite useful when it comes to prevent phishing. That's why we don't use it even for spam scoring anymore. It is not worth the resources, IMHO again at least :-) - -- Udo Rader http://www.bestsolution.at -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD4DBQFHTbkguhFd84GLxP8RAr8nAJdq02VRDE+jIHG8mF//lCgZAmBrAJ9s2hAC 1LfHpCBn1c86DJC86Fj5vw== =WYDo -END PGP SIGNATURE-
Re: [Dovecot] spf record
on 11/28/2007 10:46 AM Matt spake the following: But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve. DKIM and domainkeys are really no better in that respect. Spammers typically do not go through that much effort though. Matt I do see some benefit, at least for us. We get a lot of mail from a bank, but I cannot whitelist the bank by domain, because of phishing. So I either have to write some custom rules and experiment, whitelist each individuals address as they hit, or validate their domainkey and bump any scores back down enough to clear the filters. I think I will look at enabling the dkim plugin in spamassassin and see what happens. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't
Re: [Dovecot] SPAM: Re: spf record
I may be sorry I brought this up. There's nothing wrong with your TXT record. This server acts as a virus/spam processor for mail relayed from a legacy server (for historical reasons). It filters with MailScanner/SpamAssassin. Looking through the SpamAssassin debug code, it checks my relay as the 'Envelope-from' and fails on -all. Although the information is there, the SpamAssassin plugin isn't sophisticated enough to trace it back to the originating server. And, yes - it assigns a minor score (default 0.69) for SPF_FAIL and I don't lose any digests as Bayes just overwhelms it. As long as your unqualified domain name has an A record and a matching PTR record SPF should work just fine (as long as there aren't any relays in-between). Sorry for any inconvenience. Thanks for your excellent project. On Wed, 28 Nov 2007 17:28:32 +0200, Timo Sirainen wrote > On Wed, 2007-11-28 at 11:17 -0400, Jim Flowers wrote: > > Your spf record is broken: > > > > dovecot.org.39942 IN TXT "v=spf1 a -all" > > Care to tell also why? dovecot.org's mails are sent from the same IP > as its A record. -- Jim Flowers <[EMAIL PROTECTED]>
Re: [Dovecot] spf record
> But as a matter of fact, I got corrected. The major problem with even > scoring is that the only things spammers have to do (and they really do > it!) is to register some new domain, enter valid SPF records for it and > then their scoring might even improve. DKIM and domainkeys are really no better in that respect. Spammers typically do not go through that much effort though. Matt
Re: [Dovecot] spf record
on 11/28/2007 10:08 AM Udo Rader spake the following: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick Romero wrote: On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote: On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring. Some time ago there was a similar discussion on the postfix ML and I had pretty much the same arguments that you had. But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve. That is why you don't score on pass, but incremental score on fails. That way a fail will bump the score a bit, but a pass won't negate the other hits. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger
(Yes, Really w/ gcc v4.2.1, like i said in the first place) > Actually, the 1.1 beta v9 builds just fine under Tiger (PPC and > PPC64) if you use the official Apple sanctioned gcc v 4.01 they ship > with both Tiger and Leopard. If you do download and use gcc 4.2.1 from > the GNU folks you might want to pass along the error / bug reports to > them instead of Apple, but I suspect the GNU folks will tell you to > try the current 4.2.2 version or the new 4.3 version. i'm using Apple's gcc 4.2.1: http://www.opensource.apple.com/darwinsource/10.5/gcc_42-5531/ and the v4.2.1 Tiger equiv from the R-project provided at http://r.research.att.com/tools/ both Apple & ATT are _already_ well plugged into both .. er .. Apple & GNU. yes, 4.2.1 is "not distro" ... but it *is* up-n-coming, as evienced by the fact that it *is* offered on the darwinsource page. i'd gather tss would like to know about issues. (it shouldn't be terribly surprising for a projects' beta release to at least be _tried_ with _other_ projects' beta releases ...) cheers.
Re: [Dovecot] autogen.sh fails -> "required file `./config.rpath' not found"
> the real solution would be to copy the config.rpath [1] from your distro > into the source dir. this requires the gettext devel files to be > installed. i'm not using nls/gettext. afaict, it's not even mentioned (in configure, doc, INSTALL, etc) as an option. then, gettext shouldn't be a requirement (even though it's installed on my system ...). the point is, the check for the file is there, but the file is not included. autogen.sh *would* copy it if i spec'd the location of my gettext in /usr/local/share (odd that the check wouldn't be for 'standard' locations ... ), but, again, why's it asked for? > now the question is when using the 1.1b9 tarball. > why do you run autogen.sh at all? i'm not using the tarball -- rather hg clone -r1.1.beta9 http://hg.dovecot.org/dovecot instructions, of course, are: "If you got Dovecot from Mercurial, for instance with ---%<- hg clone http://hg.dovecot.org/dovecot/ ---%<- you will first need to run './autogen.sh' to generate the 'configure' script and some other files."
Re: [Dovecot] spf record
On Nov 28, 2007, at 12:08 PM, Udo Rader wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick Romero wrote: On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote: On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring. Some time ago there was a similar discussion on the postfix ML and I had pretty much the same arguments that you had. But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve. I only give negative points for non-matching records. No positive points. (Unless I misconfigured something, that's how I believe - and want - it to work). The idea being that even if the record doesn't match, if it's a valid email you won't have enough other negatively scoring components to completely drop it. If there is a negative match on spam then we're also compensating for changes in the structure of the email that might get it past bayesian filters. If there is no record, or a positive match, then IMHO we're really neither better nor worse off. The 'spammers create domains' argument almost negates the sender verification system entirely - assuming you're giving positive points for any valid records. Rick - -- Udo Rader http://www.bestsolution.at -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHTa6BuhFd84GLxP8RAh2uAJ43FN6z1DZkEP6Uun0CxnuA+iSukQCfcqiY bSBpLiK6MmDvahOLmYt0lTc= =zmqd -END PGP SIGNATURE-
Re: [Dovecot] spf record
Dean Brooks wrote: On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. DomainKeys at least provides a solution for the original problem; the ability to determine whether an email came from a mail server that was authorized to send from that domain, -and- the ability to embed that signature into the message itself rather than relying on only the source IP address to give that information. Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't. I second that. I've wasted a lot of time with SPF and it's useless.
Re: [Dovecot] spf record
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick Romero wrote: > > On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote: > >> On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: > Your spf record is broken: > > dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. >>> >>> Hmmm. I would have listed mx as well but thats just me. But just >>> listing a is likely better in that there are less lookups for the >>> receiving system. >>> >>> One thing that bugs me is why we must now implement domainkeys on top >>> of SPF. SPF pretty much does everything domainkeys does but simpler. >> >> Because SPF is a broken hack that doesn't properly accomodate the >> forwarding of email without the use of other complicating hacks >> such as SRS which mangle the sender address. >> >> SPF should have been scrapped years ago. Instead, most large >> organizations use "?all" in their SPF entry (typically because of the >> forwarding problem), putting SPF in advisory mode which negates the >> whole purpose of having it anyway. > > I disagree. > The only way you should be using SPF on the receiving end is as an > additional weight for spam scoring. Some time ago there was a similar discussion on the postfix ML and I had pretty much the same arguments that you had. But as a matter of fact, I got corrected. The major problem with even scoring is that the only things spammers have to do (and they really do it!) is to register some new domain, enter valid SPF records for it and then their scoring might even improve. - -- Udo Rader http://www.bestsolution.at -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHTa6BuhFd84GLxP8RAh2uAJ43FN6z1DZkEP6Uun0CxnuA+iSukQCfcqiY bSBpLiK6MmDvahOLmYt0lTc= =zmqd -END PGP SIGNATURE-
Re: [Dovecot] spf record
On Wed, Nov 28, 2007 at 11:45:29AM -0600, Rick Romero wrote: > >>One thing that bugs me is why we must now implement domainkeys on top > >>of SPF. SPF pretty much does everything domainkeys does but simpler. > > > >Because SPF is a broken hack that doesn't properly accomodate the > >forwarding of email without the use of other complicating hacks > >such as SRS which mangle the sender address. > > > >SPF should have been scrapped years ago. Instead, most large > >organizations use "?all" in their SPF entry (typically because of the > >forwarding problem), putting SPF in advisory mode which negates the > >whole purpose of having it anyway. > > I disagree. > The only way you should be using SPF on the receiving end is as an > additional weight for spam scoring. Well, perhaps, but that's not how it was originally designed to be used. I don't disagree that it has devolved into just another spam scoring device though. It's not even a very good one, since you can't easily determine if a message is simply being forwarded. As such, the score modifiers tend to be low. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger (Not Really)
On Nov 28, 2007, at 10:59 AM, [EMAIL PROTECTED] wrote: Message: 8 Date: Wed, 28 Nov 2007 07:49:13 -0800 From: snowcrash <[EMAIL PROTECTED]> Subject: Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create) To: "Timo Sirainen" <[EMAIL PROTECTED]> Cc: Dovecot Mailing List Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 (lots of messages from the digest snipped out) Actually, the 1.1 beta v9 builds just fine under Tiger (PPC and PPC64) if you use the official Apple sanctioned gcc v 4.01 they ship with both Tiger and Leopard. If you do download and use gcc 4.2.1 from the GNU folks you might want to pass along the error / bug reports to them instead of Apple, but I suspect the GNU folks will tell you to try the current 4.2.2 version or the new 4.3 version. Jerry smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] spf record
On Nov 28, 2007, at 11:26 AM, Dean Brooks wrote: On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. I disagree. The only way you should be using SPF on the receiving end is as an additional weight for spam scoring. That covers forwarding, ddns home users, and misc other issues. Not only can you not be assured that an email is sent from a particular host, but you can't be assured everyone's upstream DNS has cached your record properly. IMHO, to assume a DNS record is going to be kept up to date and correct 100% of the time is just silly.By requiring an exact match to prevent a rejection, those who do this are risking many outright rejections which negatively affect their perceived service levels. Rick
Re: [Dovecot] spf record
> > One thing that bugs me is why we must now implement domainkeys on top > > of SPF. SPF pretty much does everything domainkeys does but simpler. > > Because SPF is a broken hack that doesn't properly accomodate the > forwarding of email without the use of other complicating hacks > such as SRS which mangle the sender address. > > SPF should have been scrapped years ago. Instead, most large > organizations use "?all" in their SPF entry (typically because of the > forwarding problem), putting SPF in advisory mode which negates the > whole purpose of having it anyway. > > DomainKeys at least provides a solution for the original problem; the > ability to determine whether an email came from a mail server that > was authorized to send from that domain, -and- the ability to embed > that signature into the message itself rather than relying on only the > source IP address to give that information. > > Everyone has different opinions on the usefulness of SPF, but the > reality of it is, DomainKeys solves the entire problem. SPF doesn't. Where does DKIM fit in all this? Could Exim compile it in without the license restrictions of domainkeys? I use Directadmin which is based on exim and dovecot. http://wiki.exim.org/DomainKeys http://wiki.exim.org/DKIM Matt
Re: [Dovecot] spf record
(Dean, sorry you'll see this twice...I forget that the Dovecot list, unlike every other list I'm subscribed to, does not "reply to list" by default...) Dean Brooks wrote: > Everyone has different opinions on the usefulness of SPF, but the > reality of it is, DomainKeys solves the entire problem. SPF doesn't. > > -- > Dean Brooks > [EMAIL PROTECTED] Yes, but DomainKeys suffers from patent bloat and restrictive licensing, which is antithetical to the open-source ideals of projects such as Dovecot. ...thanks so much, Yahoo RobertC
Re: [Dovecot] autogen.sh fails -> "required file `./config.rpath' not found"
On 2007-11-28 08:47:14 -0800, snowcrash wrote: > on fresh 1.1.beta9 source, it fails @ > > ./autogen.sh > ... > 100%[>] 154,427 > 115.09K/s > > 08:45:56 (114.82 KB/s) - `wiki-export.tar.gz' saved > [154427/154427] > > configure.in:16: required file `./config.rpath' not found > configure.in:5: installing `./missing' > configure.in:5: installing `./install-sh' > src/auth/Makefile.am: installing `./depcomp' > autoreconf: automake failed with exit status: 1 > > per advice, > > "gettext-related test failures: config.rpath presence" > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00426.html > > a simple > > touch config.rpath > ./autogen.sh > > fixes the problem. the real solution would be to copy the config.rpath [1] from your distro into the source dir. this requires the gettext devel files to be installed. now the question is when using the 1.1b9 tarball. why do you run autogen.sh at all? darix [1] /usr/share/gettext/config.rpath on my distro -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] spf record
On Wed, Nov 28, 2007 at 11:06:40AM -0600, Matt wrote: > > > Your spf record is broken: > > > > > > dovecot.org.39942 IN TXT "v=spf1 a -all" > > > > Care to tell also why? dovecot.org's mails are sent from the same IP as > > its A record. > > Hmmm. I would have listed mx as well but thats just me. But just > listing a is likely better in that there are less lookups for the > receiving system. > > One thing that bugs me is why we must now implement domainkeys on top > of SPF. SPF pretty much does everything domainkeys does but simpler. Because SPF is a broken hack that doesn't properly accomodate the forwarding of email without the use of other complicating hacks such as SRS which mangle the sender address. SPF should have been scrapped years ago. Instead, most large organizations use "?all" in their SPF entry (typically because of the forwarding problem), putting SPF in advisory mode which negates the whole purpose of having it anyway. DomainKeys at least provides a solution for the original problem; the ability to determine whether an email came from a mail server that was authorized to send from that domain, -and- the ability to embed that signature into the message itself rather than relying on only the source IP address to give that information. Everyone has different opinions on the usefulness of SPF, but the reality of it is, DomainKeys solves the entire problem. SPF doesn't. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] spf record
On Nov 28, 2007, at 11:06 AM, Matt wrote: Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. My SPF record originally only had mx and my ip block (Which contains all my servers). Had no problems for 2 years. A week or two ago a user complained one domain (some programmers domain which I thought was amusing) was rejecting based on SPF, and it turns out they only worked with the 'a' listing in there. They were running Exchange.. Just an FYI.. cover all your bases :/ Rick
Re: [Dovecot] spf record
> > Your spf record is broken: > > > > dovecot.org.39942 IN TXT "v=spf1 a -all" > > Care to tell also why? dovecot.org's mails are sent from the same IP as > its A record. Hmmm. I would have listed mx as well but thats just me. But just listing a is likely better in that there are less lookups for the receiving system. One thing that bugs me is why we must now implement domainkeys on top of SPF. SPF pretty much does everything domainkeys does but simpler. Implementing domainkeys I hear will require Exim be recompilled on the machine it needs to be used on too. http://wiki.exim.org/DomainKeys Matt
Re: [Dovecot] spf record
11/28/2007 7:17 AM Jim Flowers spake the following: Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" -- Jim Flowers <[EMAIL PROTECTED]> Checking to see if there is a valid SPF record. Found v=spf1 record for dovecot.org v=spf1 a -all evaluating... SPF record passed validation test with pySPF (Python SPF library)!on -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't
[Dovecot] autogen.sh fails -> "required file `./config.rpath' not found"
if i run autogen.sh on fresh 1.1.beta9 source, it fails @ ./autogen.sh ... 100%[>] 154,427 115.09K/s 08:45:56 (114.82 KB/s) - `wiki-export.tar.gz' saved [154427/154427] configure.in:16: required file `./config.rpath' not found configure.in:5: installing `./missing' configure.in:5: installing `./install-sh' src/auth/Makefile.am: installing `./depcomp' autoreconf: automake failed with exit status: 1 per advice, "gettext-related test failures: config.rpath presence" http://www.mail-archive.com/[EMAIL PROTECTED]/msg00426.html a simple touch config.rpath ./autogen.sh fixes the problem. hth
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
> it was not. now that _you've_ mentioned it, i'll try it and see. fyi ... this looks better, now. setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib -L/usr/local/mysql/lib/mysql -L/usr/local/lib" setenv LIBS "-liconv" setenv SQL_LIBS "-lsqlite3" setenv CPPFLAGS "-I/usr/local/db46/include -I/usr/local/sqlite/include -I/usr/local/mysql/include/mysql -I/usr/local/include" ./configure \ --config-cache \ --prefix=/usr/local/dovecot \ --with-moduledir=/usr/local/dovecot-plugins \ --with-libiconv-prefix=/usr/local \ --with-ssl=openssl \ --with-ssldir=/var/CERTS \ --enable-maintainer-mode \ --disable-debug \ --enable-ipv6 \ --disable-static --enable-shared \ --with-db \ --with-mysql \ --with-sqlite \ --with-ioloop=best \ --with-sql-drivers=mysql,sqlite \ --with-deliver \ --with-pop3d \ --with-storages=maildir,mbox,dbox,cydir,raw otool -L sbin/dovecot sbin/dovecotpw libexec/dovecot/dovecot-auth sbin/dovecot: /usr/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) sbin/dovecotpw: /usr/lib/libpam.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib (compatibility version 16.0.0, current version 16.0.0) /usr/local/ssl/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/ssl/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/local/sqlite/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/local/lib/libncurses.5.6.dylib (compatibility version 5.6.0, current version 5.6.0) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) libexec/dovecot/dovecot-auth: /usr/lib/libpam.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib (compatibility version 16.0.0, current version 16.0.0) /usr/local/ssl/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/ssl/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/local/sqlite/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/local/lib/libncurses.5.6.dylib (compatibility version 5.6.0, current version 5.6.0) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) (*should* there be any links to -ldb in there?) cheers!
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
> That's why libraries shouldn't be added to them, only linker flags. agreed. which i would have done if SQL_LIBS had been mentioned in "./configure --help" output. adding to LIBS had not worked ... it was not. now that _you've_ mentioned it, i'll try it and see.
Re: [Dovecot] imap process killed with signal 11
On Wed, 28 Nov 2007 08:30:41 +0200 Timo Sirainen <[EMAIL PROTECTED]> wrote: > On Tue, 2007-11-27 at 16:54 +, Daniel wrote: > > On Mon, 26 Nov 2007 14:49:01 +0200 > > Timo Sirainen <[EMAIL PROTECTED]> wrote: > > > > > On Sun, 2007-11-25 at 13:39 +, Daniel wrote: > > > > Using the latest cvs from HEAD, I'm experiencing problems after > > > > sending a message and the client is trying upload the message > > > > to the appropriate (Sent/Queue) folder. I get only one error in > > > > dovecot.log: dovecot: Nov 25 14:21:31 Error: child 19554 (imap) > > > > killed with signal 11 > > > > > > Could you get gdb backtrace from this crash? Otherwise I can't > > > really do anything about it. See http://dovecot.org/bugreport.html > > > > > Sure: > > > > (gdb) bt full > > #0 0x1c04af71 in mail_cache_field_exists () > > No symbol table info available. > > #1 0x1c04cb4c in mail_cache_field_can_add () > > No symbol table info available. > > #2 0x1c041b9d in index_mail_cache_add_idx () > > No symbol table info available. > > #3 0x1c041c5c in index_mail_cache_add_idx () > > No symbol table info available. > > #4 0x1c04259d in index_mail_close () > > I thought this got fixed last friday? > http://hg.dovecot.org/dovecot/rev/9ca7f055b646 > > If it's still happening with beta9/latest hg, could you get the > backtrace again with debug symbols? (Debug symbols should be in > binaries automatically, I guess you stripped them at some point) I got your other mail, it is working now, thanks! Daniel
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
On Wed, 2007-11-28 at 07:49 -0800, snowcrash wrote: > > I think as a user it's a lot easier to use and understand if you're just > > instructed to say: > > > CPPFLAGS=-I/usr/local/include LDFLAGS=-I/usr/local/lib ./configure > > > > instead of: > > > > ./configure --with-mysql=/usr/local --with-sqlite=/usr/local > > --with-pgsql=/usr/local --with-ten-other-packages=/usr/local > > again, i don't agree. LDFLAGS, CPPFLAGS, etc are _global_ var > instances ... used by autofoo across the entier install. often end up > with stuff linked-in where you don't necessarily need/want it. That's why libraries shouldn't be added to them, only linker flags. > > -I and -L don't really matter if they're in global CPPFLAGS/LDFLAGS. > > hm? items def'd in LDFLAGS don't matter? then why your question about > why -lsqlite is linked in? it's _only_ coming from LDFLAGS ... > apparently not as you expected, no? You showed that you added it to LDFLAGS yourself. Dovecot should be adding it automatically where needed. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
> I think as a user it's a lot easier to use and understand if you're just > instructed to say: > CPPFLAGS=-I/usr/local/include LDFLAGS=-I/usr/local/lib ./configure > > instead of: > > ./configure --with-mysql=/usr/local --with-sqlite=/usr/local > --with-pgsql=/usr/local --with-ten-other-packages=/usr/local again, i don't agree. LDFLAGS, CPPFLAGS, etc are _global_ var instances ... used by autofoo across the entier install. often end up with stuff linked-in where you don't necessarily need/want it. also, lots of other apps seem to provide the option. i suppose they do it for a reason ... but it's simply personal preference -- and, like i said, ultimately your call! :-) > Binary packages sometimes install things to different locations than a > standard installation. Like the header might not be in /usr/include/, > but in /usr/include/package/. For that case this doesn't really work. well, first, i don't *use* binary packages ... i build from source. but, anyway, it works just fine -- if you define/ues the vars properly. i do it all the time with other apps. > And lots of bloat to both configure code and ./configure --help.. some say bloat, some say flexibility. again, just opinion. if lean-as-possible is the goal, then you're absolutely right. if, however, you want to allow folks to built dovecot on *their* system layout -- not just distros' -- then some flexibility needs to be there. > -I and -L don't really matter if they're in global CPPFLAGS/LDFLAGS. hm? items def'd in LDFLAGS don't matter? then why your question about why -lsqlite is linked in? it's _only_ coming from LDFLAGS ... apparently not as you expected, no? anyway, i can simply workaround lack of flexibility if/as needed. no changes to 'required'. cheers.
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
On Wed, 2007-11-28 at 16:34 +0100, Mark Heitmann wrote: > > > > >/ It looks like your LDAP library is just returning a wrong file > > />/ descriptor, and there's nothing I can do about that in Dovecot's side. > > />/ Use OpenLDAP instead. > > / > > Looks like someone else has found this too: > > > > http://bugs.opensolaris.org/view_bug.do;jsessionid=868c93415e3b4b73aa32fe63eb730?bug_id=6551471 > > > I'm using OpenLDAP and try the versions 2.3.38 and 2.4.6. The described > bug in the opensolaris board refer IMO to the Solaris ldap library. Oh. I guess I should then remove that comment I added to code. :) > I will now try some dtrace scripts to find out more about the problem. What > amazes me, is that all other programs on this mail machine have no problems > with the openldap installation ... Most programs use blocking LDAP library calls and they don't care about the file descriptor. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] How to find an invalid configuration in dovecot.conf
On Wed, 2007-11-28 at 16:30 +0100, Laurent PELLISSIER wrote: > Timo Sirainen a écrit : > > > These happen only if you're trying to use Dovecot from inetd. Do you > > really need it? I'd suggest running dovecot directly, it works a lot > > better and most likely gives better error messages as well. > > I run it (compiled by myself) from the command line in the foreground > to try to debug it : > > # /opt/dovecot/sbin/dovecot -F -c /etc/dovecot.conf What if you try to connect to imap port without running it? Does it give connection refused? Because that error message really looks like you've configured Dovecot to start from inetd. signature.asc Description: This is a digitally signed message part
[Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
>/ It looks like your LDAP library is just returning a wrong file />/ descriptor, and there's nothing I can do about that in Dovecot's side. />/ Use OpenLDAP instead. / Looks like someone else has found this too: http://bugs.opensolaris.org/view_bug.do;jsessionid=868c93415e3b4b73aa32fe63eb730?bug_id=6551471 I'm using OpenLDAP and try the versions 2.3.38 and 2.4.6. The described bug in the opensolaris board refer IMO to the Solaris ldap library. I will now try some dtrace scripts to find out more about the problem. What amazes me, is that all other programs on this mail machine have no problems with the openldap installation ... Mark
Re: [Dovecot] How to find an invalid configuration in dovecot.conf
Timo Sirainen a écrit : These happen only if you're trying to use Dovecot from inetd. Do you really need it? I'd suggest running dovecot directly, it works a lot better and most likely gives better error messages as well. I run it (compiled by myself) from the command line in the foreground to try to debug it : # /opt/dovecot/sbin/dovecot -F -c /etc/dovecot.conf -- Laurent PELLISSIER @ Ecole des Mines d'Alès
Re: [Dovecot] spf record
On Wed, 2007-11-28 at 11:17 -0400, Jim Flowers wrote: > Your spf record is broken: > > dovecot.org.39942 IN TXT "v=spf1 a -all" Care to tell also why? dovecot.org's mails are sent from the same IP as its A record. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] How to find an invalid configuration in dovecot.conf
On Wed, 2007-11-28 at 16:08 +0100, Laurent PELLISSIER wrote: > dovecot: Nov 28 15:43:53 Error: IMAP(lavande): Error: Dovecot is already > running with PID 4369 (read from > /opt/dovecot-1.0.8/var/run/dovecot/master.pid) > dovecot: Nov 28 15:43:53 Error: IMAP(lavande): Fatal: Invalid > configuration in /etc/dovecot.conf > dovecot: Nov 28 15:43:53 Error: IMAP(lavande): Fatal: EOF while reading > environment from master These happen only if you're trying to use Dovecot from inetd. Do you really need it? I'd suggest running dovecot directly, it works a lot better and most likely gives better error messages as well. signature.asc Description: This is a digitally signed message part
[Dovecot] spf record
Your spf record is broken: dovecot.org.39942 IN TXT "v=spf1 a -all" -- Jim Flowers <[EMAIL PROTECTED]> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
On Wed, 2007-11-28 at 07:04 -0800, snowcrash wrote: > > Doesn't it have -lmysqlclient at all? > > on this box, yes, it does: .. > > Should I just add another > > -lmysqlclient_r check and use it if -lmysqlclient isn't found? > > you can add a conditional ... but, imho, you need the option to > _specify_ using the threaded libs,not just fallback to them. Since Dovecot doesn't use threads, why do you want to link with mysqlclient_r then? > > > setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib > > > -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv" > > .. > > > iirc, the "--with-sqlite" config option does not take a DIR arg. so > > > to tell it where, LDFLAGS are req'd. > > > > The -L parameters are good enough in there, but isn't -lsqlite3 added > > automatically? If not, put it to SQL_LIBS instead if LDFLAGS. > > aha -- SQL_LIBS. > > you might wish to add mention of that to: ... > personally, i find it a lot LESS confusing than having to dig for / > guess if an env var SQLITE3_LIBS exists ... You don't have to use SQL_LIBS for anything else except -lsqlite3, if you really want to add that. --with-sqlite=/path wouldn't go adding -lsqlite3 anywhere either, so it wouldn't help. I think as a user it's a lot easier to use and understand if you're just instructed to say: CPPFLAGS=-I/usr/local/include LDFLAGS=-I/usr/local/lib ./configure instead of: ./configure --with-mysql=/usr/local --with-sqlite=/usr/local --with-pgsql=/usr/local --with-ten-other-packages=/usr/local And then you'll have 13 -I/usr/local/include and -L/usr/local/lib parameters, unless of course I add more code to remove those. > --with-mysql=DIR DIR is the install prefix Binary packages sometimes install things to different locations than a standard installation. Like the header might not be in /usr/include/, but in /usr/include/package/. For that case this doesn't really work. > or 'all three' > > --with-mysql=DIRDIR is the install prefix > --with-mysql-libs=DIR overrides the DIR where libmysqlclient(_r).* is > --with-mysql-includes=DIR overrides the DIR where mysql.h is And lots of bloat to both configure code and ./configure --help.. > or some such. > > > They just modify the generic CPPFLAGS/LDFLAGS > > only if you defined it that way. one can readily defined > --with-mysql=$var, then assign DOVECOT_MYSQL_LIBS=$/var/mysql/libs > (e.g), and use it specifically, rather than the generic/global LDFLAGS -I and -L don't really matter if they're in global CPPFLAGS/LDFLAGS. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
(agh! bounced ...) > Doesn't it have -lmysqlclient at all? on this box, yes, it does: ls /usr/local/mysql/lib/mysql/libmysqlclient* /usr/local/mysql/lib/mysql/libmysqlclient.15.0.0.dylib /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib /usr/local/mysql/lib/mysql/libmysqlclient.a /usr/local/mysql/lib/mysql/libmysqlclient.dylib /usr/local/mysql/lib/mysql/libmysqlclient.la /usr/local/mysql/lib/mysql/libmysqlclient_r.15.0.0.dylib /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib /usr/local/mysql/lib/mysql/libmysqlclient_r.a /usr/local/mysql/lib/mysql/libmysqlclient_r.dylib /usr/local/mysql/lib/mysql/libmysqlclient_r.la > Should I just add another > -lmysqlclient_r check and use it if -lmysqlclient isn't found? you can add a conditional ... but, imho, you need the option to _specify_ using the threaded libs,not just fallback to them. > > setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib > > -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv" > .. > > iirc, the "--with-sqlite" config option does not take a DIR arg. so > > to tell it where, LDFLAGS are req'd. > > The -L parameters are good enough in there, but isn't -lsqlite3 added > automatically? If not, put it to SQL_LIBS instead if LDFLAGS. aha -- SQL_LIBS. you might wish to add mention of that to: ./configure --help | grep -i SQL --with-sql=yes|plugin Build with generic SQL support --with-pgsqlBuild with PostgreSQL driver support --with-mysqlBuild with MySQL driver support --with-sqlite Build with SQLite3 driver support --with-sql-drivers Build with specified SQL drivers (all) > > i might suggest DIR options for spec'n of non-standard install loc'ns > > for each opt. no? > > I just wrote about this privately to another guy, here's some > copy&pasting: > > Also I think those --with-package=/path parameters' functionality could > be misundertood easily. They don't really specify that the given package > is used from /path. They just modify the generic CPPFLAGS/LDFLAGS > environment and let the compiler/linker find the packages wherever they > happen to be first in the path. > > Also I could never figure out when compiling other systems what I should > use as the package path. Does the configure script use the given path as > base path for /include and /lib, or does it assume that both > the include and lib files are there or something else? What if I have > the include and lib files in completely different locations? > > I've never liked those parameters either as a user or as a developer, so > I doubt I'll ever add them to Dovecot. that's, of course, your call ... but, honestly, all of it's easily -- and frequently -- dealt with. you simply say what you mean. when clearly stated, there's no room for misunderstanding; and that explanation is completely in your hands. e.g., either just provide --with-mysql=DIR DIR is the install prefix or 'all three' --with-mysql=DIRDIR is the install prefix --with-mysql-libs=DIR overrides the DIR where libmysqlclient(_r).* is --with-mysql-includes=DIR overrides the DIR where mysql.h is or some such. > They just modify the generic CPPFLAGS/LDFLAGS only if you defined it that way. one can readily defined --with-mysql=$var, then assign DOVECOT_MYSQL_LIBS=$/var/mysql/libs (e.g), and use it specifically, rather than the generic/global LDFLAGS personally, i find it a lot LESS confusing than having to dig for / guess if an env var SQLITE3_LIBS exists ... just my $0.02! cheers.
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
> Problem was that it was reading a 50MB mail in 12kB blocks, and Dovecot > wasn't handling that very well. Fixed: > > http://hg.dovecot.org/dovecot-1.0/rev/0fba164c6ba6 > http://hg.dovecot.org/dovecot-1.0/rev/edd95f9c6ba4 That's awesome! Thanks so much Timo, you always come through! I'll install the fixes ASAP. Jackie --- Jackie Hunt ACNSVoice: (970) 663-3789 Colorado State University FAX:(970) 491-1958 Fort Collins, CO 80523 Email: [EMAIL PROTECTED]
[Dovecot] How to find an invalid configuration in dovecot.conf
Hi, I'm trying to test Dovecot as an IMAP ans POP3 server but I ran into a fatal problem. On the client side (telnet) I'm trying very basic IMAP commands : $ telnet localhost imap Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. * OK Dovecot ready. 1 LOGIN lavande secret 1 OK Logged in. Connection closed by foreign host. The login succeeds but the connection hangs ! On the server side it complains that the configuration file dovecot.conf is invalid (it was copied from dovecot-example.conf) but it never tells what line number is incorrect. dovecot -a or dovecot -n doesn't complain about a syntax error or something. It works for POP3 for the same user/pass. # /opt/dovecot/sbin/dovecot -F -c /etc/dovecot.conf dovecot: Nov 28 15:43:42 Info: Dovecot v1.0.8 starting up dovecot: Nov 28 15:43:53 Info: imap-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured dovecot: Nov 28 15:43:53 Error: IMAP(lavande): Error: Dovecot is already running with PID 4369 (read from /opt/dovecot-1.0.8/var/run/dovecot/master.pid) dovecot: Nov 28 15:43:53 Error: IMAP(lavande): Fatal: Invalid configuration in /etc/dovecot.conf dovecot: Nov 28 15:43:53 Error: IMAP(lavande): Fatal: EOF while reading environment from master dovecot: Nov 28 15:43:53 Error: child 4380 (imap) returned error 89 Best regards, -- Laurent PELLISSIER @ Ecole des Mines d'Alès
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
> Doesn't it have -lmysqlclient at all? on this box, yes, it does: ls /usr/local/mysql/lib/mysql/libmysqlclient* /usr/local/mysql/lib/mysql/libmysqlclient.15.0.0.dylib /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib /usr/local/mysql/lib/mysql/libmysqlclient.a /usr/local/mysql/lib/mysql/libmysqlclient.dylib /usr/local/mysql/lib/mysql/libmysqlclient.la /usr/local/mysql/lib/mysql/libmysqlclient_r.15.0.0.dylib /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib /usr/local/mysql/lib/mysql/libmysqlclient_r.a /usr/local/mysql/lib/mysql/libmysqlclient_r.dylib /usr/local/mysql/lib/mysql/libmysqlclient_r.la > Should I just add another > -lmysqlclient_r check and use it if -lmysqlclient isn't found? you can add a conditional ... but, imho, you need the option to _specify_ using the threaded libs,not just fallback to them. > > setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib > > -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv" > .. > > iirc, the "--with-sqlite" config option does not take a DIR arg. so > > to tell it where, LDFLAGS are req'd. > > The -L parameters are good enough in there, but isn't -lsqlite3 added > automatically? If not, put it to SQL_LIBS instead if LDFLAGS. aha -- SQL_LIBS. you might wish to add mention of that to: ./configure --help | grep -i SQL --with-sql=yes|plugin Build with generic SQL support --with-pgsqlBuild with PostgreSQL driver support --with-mysqlBuild with MySQL driver support --with-sqlite Build with SQLite3 driver support --with-sql-drivers Build with specified SQL drivers (all) > > i might suggest DIR options for spec'n of non-standard install loc'ns > > for each opt. no? > > I just wrote about this privately to another guy, here's some > copy&pasting: > > Also I think those --with-package=/path parameters' functionality could > be misundertood easily. They don't really specify that the given package > is used from /path. They just modify the generic CPPFLAGS/LDFLAGS > environment and let the compiler/linker find the packages wherever they > happen to be first in the path. > > Also I could never figure out when compiling other systems what I should > use as the package path. Does the configure script use the given path as > base path for /include and /lib, or does it assume that both > the include and lib files are there or something else? What if I have > the include and lib files in completely different locations? > > I've never liked those parameters either as a user or as a developer, so > I doubt I'll ever add them to Dovecot. that's, of course, your call ... but, honestly, all of it's easily -- and frequently -- dealt with. you simply say what you mean. when clearly stated, there's no room for misunderstanding; and that explanation is completely in your hands. e.g., either just provide --with-mysql=DIR DIR is the install prefix or 'all three' --with-mysql=DIRDIR is the install prefix --with-mysql-libs=DIR overrides the DIR where libmysqlclient(_r).* is --with-mysql-includes=DIR overrides the DIR where mysql.h is or some such. > They just modify the generic CPPFLAGS/LDFLAGS only if you defined it that way. one can readily defined --with-mysql=$var, then assign DOVECOT_MYSQL_LIBS=$/var/mysql/libs (e.g), and use it specifically, rather than the generic/global LDFLAGS personally, i find it a lot LESS confusing than having to dig for / guess if an env var SQLITE3_LIBS exists ... just my $0.02! cheers.
Re: [Dovecot] quick question about fs quota overhead in plugin
On Wed, 2007-11-28 at 09:26 -0500, Adam McDougall wrote: > Last night I enabled imap_quota so dovecot could report usage reported > by disk quota. I don't intend to actually use the quota plugin to place > any limits anytime soon though. How much overhead does this add to > normal operations that allocate disk space? Ideally I'd like a situation > where the only overhead is incurred when the user uses the mail client to > specifically check their usage. Is that possible, and/or is there a better > way to do this? If it does cause general overhead on the NFS filer, I could > just accept it until/unless I feel it becomes a burden I cannot bear. > > mail_plugins = acl fts fts_squat quota imap_quota > ... > quota = fs > ... http://hg.dovecot.org/dovecot/rev/1d0521b7151d signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
On Wed, 2007-11-28 at 06:18 -0800, snowcrash wrote: > perl -pi -e 's/AC_CHECK_LIB\(mysqlclient,/AC_CHECK_LIB\(mysqlclient_r,/g' > configure.in > perl -pi -e 's/mysql_lib=\"\-lmysqlclient \-lz > \-lm"/mysql_lib=\"\-lmysqlclient_r \-lz \-lm\"/g' configure.in Doesn't it have -lmysqlclient at all? Should I just add another -lmysqlclient_r check and use it if -lmysqlclient isn't found? > setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib > -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv" .. > iirc, the "--with-sqlite" config option does not take a DIR arg. so > to tell it where, LDFLAGS are req'd. The -L parameters are good enough in there, but isn't -lsqlite3 added automatically? If not, put it to SQL_LIBS instead if LDFLAGS. > i might suggest DIR options for spec'n of non-standard install loc'ns > for each opt. no? I just wrote about this privately to another guy, here's some copy&pasting: Also I think those --with-package=/path parameters' functionality could be misundertood easily. They don't really specify that the given package is used from /path. They just modify the generic CPPFLAGS/LDFLAGS environment and let the compiler/linker find the packages wherever they happen to be first in the path. Also I could never figure out when compiling other systems what I should use as the package path. Does the configure script use the given path as base path for /include and /lib, or does it assume that both the include and lib files are there or something else? What if I have the include and lib files in completely different locations? I've never liked those parameters either as a user or as a developer, so I doubt I'll ever add them to Dovecot. signature.asc Description: This is a digitally signed message part
[Dovecot] quick question about fs quota overhead in plugin
Last night I enabled imap_quota so dovecot could report usage reported by disk quota. I don't intend to actually use the quota plugin to place any limits anytime soon though. How much overhead does this add to normal operations that allocate disk space? Ideally I'd like a situation where the only overhead is incurred when the user uses the mail client to specifically check their usage. Is that possible, and/or is there a better way to do this? If it does cause general overhead on the NFS filer, I could just accept it until/unless I feel it becomes a burden I cannot bear. mail_plugins = acl fts fts_squat quota imap_quota ... quota = fs ...
Re: [Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)
hi timo, > > it's _not_ broken on Leopard, it was "broken" on Tiger > > Oh, interesting. I guess I won't add this workaround to Dovecot sources > then. People have been building Dovecot on OSX for a long time and > no-one's complained about this before. so have i ... but, i'd gather they've _not_ been using 1.1.b9 & 'new' gcc 4.2.1 ... especially on Tiger. v421 is a different beast, with more rigorous checking, and some different option support ... i'd bet it's related. but not sure atm :-| > > > Why is it linking any of -lreadline -lncurses -lpthread anyway? What > > > line do they exist in Makefile? Does config.log say something about > > > them? > .. > > coming along from sqlite3, i believe ... > > So, the next question: Why is sqlite3 linked to anything else than > dovecot-auth? :) probably a pickup from LDFLAGS, as i config/build as: patch -p1 < /usr/ports/dovecot/patch-hash-dovecot.txt # find libmysqlclient_r perl -pi -e 's/AC_CHECK_LIB\(mysqlclient,/AC_CHECK_LIB\(mysqlclient_r,/g' configure.in perl -pi -e 's/mysql_lib=\"\-lmysqlclient \-lz \-lm"/mysql_lib=\"\-lmysqlclient_r \-lz \-lm\"/g' configure.in setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv" setenv CPPFLAGS "-I/usr/local/db46/include -I/usr/local/sqlite/include -I/usr/local/mysql/include/mysql -I/usr/local/include" ./configure \ --config-cache \ --prefix=/usr/local/dovecot \ --with-moduledir=/usr/local/dovecot-plugins \ --with-libiconv-prefix=/usr/local \ --with-ssl=openssl \ --with-ssldir=/var/CERTS \ --enable-maintainer-mode \ --disable-debug \ --enable-ipv6 \ --disable-static --enable-shared \ --with-ioloop=best \ --with-db \ --with-mysql \ --with-sqlite \ --with-sql-drivers=mysql,sqlite \ --with-deliver \ --with-pop3d \ --with-storages=maildir,mbox,dbox,cydir,raw iirc, the "--with-sqlite" config option does not take a DIR arg. so to tell it where, LDFLAGS are req'd. i might suggest DIR options for spec'n of non-standard install loc'ns for each opt. no? hth.
[Dovecot] v1.0.8 released
http://dovecot.org/releases/1.0/dovecot-1.0.8.tar.gz
http://dovecot.org/releases/1.0/dovecot-1.0.8.tar.gz.sig
+ Authentication: Added "password_noscheme" field that can be used
instead of "password". "password" treats "{prefix}" as a password
scheme while "password_noscheme" treats it as part of the password
itself. So "password_noscheme" should be used if you're storing
passwords as plaintext. Non-plaintext passwords never begin
with "{", so this isn't a problem with them.
- IMAP: Partial body fetching was sometimes non-optimal, causing
the entire message to be read for every FETCH command.
- deliver failed to save the message when envelope sender address
contained spaces.
- Maildir++ quota: We could have randomly recalculated quota when
it wasn't necessary.
- Login process could have crashed after logging in if client sent
data before "OK Logged in" reply was sent (i.e. before master had
replied that login succeeded).
- Don't assert-crash when reading dovecot.index.logs generated by
Dovecot v1.1.
- Authentication: Don't assert-crash if password beings with "{" but
doesn't contain "}".
- Authentication cache didn't work when using settings that changed
the username (e.g. auth_username_format).
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
On Wed, 2007-11-28 at 15:55 +0200, Timo Sirainen wrote:
> On Wed, 2007-11-28 at 14:41 +0100, Mark Heitmann wrote:
> > > + if (conn->fd <= 3)
> > > + i_error("LDAP returned wrong fd %d", conn->fd);
> > > i_assert(conn->fd != -1);
> > > net_set_nonblock(conn->fd, TRUE);
> > > }
> >
> > Okay, with the little debug patch, this ist the output from my
> > dovecot.log when dovecot starts
> >
> > dovecot: Nov 28 14:37:04 Error: auth(default): LDAP returned wrong fd 1
>
> It looks like your LDAP library is just returning a wrong file
> descriptor, and there's nothing I can do about that in Dovecot's side.
> Use OpenLDAP instead.
Looks like someone else has found this too:
http://bugs.opensolaris.org/view_bug.do;jsessionid=868c93415e3b4b73aa32fe63eb730?bug_id=6551471
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
On Wed, 2007-11-28 at 14:41 +0100, Mark Heitmann wrote:
> > + if (conn->fd <= 3)
> > + i_error("LDAP returned wrong fd %d", conn->fd);
> > i_assert(conn->fd != -1);
> > net_set_nonblock(conn->fd, TRUE);
> > }
>
> Okay, with the little debug patch, this ist the output from my
> dovecot.log when dovecot starts
>
> dovecot: Nov 28 14:37:04 Error: auth(default): LDAP returned wrong fd 1
It looks like your LDAP library is just returning a wrong file
descriptor, and there's nothing I can do about that in Dovecot's side.
Use OpenLDAP instead.
signature.asc
Description: This is a digitally signed message part
[Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
On Wed, 2007-11-28 at 10:22 +0200, Timo Sirainen wrote:
>/ On Wed, 2007-11-28 at 09:10 +0100, Mark Heitmann wrote:
/>/ > pollsys(0x08099448, 11, 0x08047B10, 0x) = 1
/>/ > fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0
/>/ > fd=7 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0
/>/ > fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL
rev=POLLIN|POLLPRI
/>/
/>/ Looks like this is the problem. fd=1 should /dev/null and it should
/>/ never be passed to poll(). I'll try to look more into this later today.
/
See if this patch starts logging errors:
diff -r edd95f9c6ba4 src/auth/db-ldap.c
--- a/src/auth/db-ldap.cWed Nov 28 08:11:17 2007 +0200
+++ b/src/auth/db-ldap.cWed Nov 28 15:27:34 2007 +0200
@@ -513,6 +513,8 @@ static void db_ldap_get_fd(struct ldap_c
i_fatal("LDAP: Can't get connection fd: %s",
ldap_err2string(ret));
}
+ if (conn->fd <= 3)
+ i_error("LDAP returned wrong fd %d", conn->fd);
i_assert(conn->fd != -1);
net_set_nonblock(conn->fd, TRUE);
}
Okay, with the little debug patch, this ist the output from my
dovecot.log when dovecot starts
dovecot: Nov 28 14:37:04 Error: auth(default): LDAP returned wrong fd 1
Mark
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
On Wed, 2007-11-28 at 10:22 +0200, Timo Sirainen wrote:
> On Wed, 2007-11-28 at 09:10 +0100, Mark Heitmann wrote:
> > pollsys(0x08099448, 11, 0x08047B10, 0x) = 1
> > fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0
> > fd=7 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0
> > fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN|POLLPRI
>
> Looks like this is the problem. fd=1 should /dev/null and it should
> never be passed to poll(). I'll try to look more into this later today.
See if this patch starts logging errors:
diff -r edd95f9c6ba4 src/auth/db-ldap.c
--- a/src/auth/db-ldap.cWed Nov 28 08:11:17 2007 +0200
+++ b/src/auth/db-ldap.cWed Nov 28 15:27:34 2007 +0200
@@ -513,6 +513,8 @@ static void db_ldap_get_fd(struct ldap_c
i_fatal("LDAP: Can't get connection fd: %s",
ldap_err2string(ret));
}
+ if (conn->fd <= 3)
+ i_error("LDAP returned wrong fd %d", conn->fd);
i_assert(conn->fd != -1);
net_set_nonblock(conn->fd, TRUE);
}
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] IMAP --> Creating Folders --> trailing slash
On Wed, 2007-11-28 at 12:00 +0100, Andre Hübner wrote: > i use Dovecot 1.0.7 for pop and imap on Suse Linux 10.1. I need a little > help in understanding something. > If i want to create a folder with outlook express or thunderbird which can > also create subfolders, then i have to create these folders with a trailing > slash. > folders created with trailing slash are in filesystem created als real > folders, "normal" folders are created as file. > Is it possible to change this behavior? I want to create a folders just by > typing a name without trailing slash. It should be possible to store > messages in this folder or create subfolders. > Is there any workaround to achieve this goal? Use maildir format instead of mbox. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] little submissions feature request
On Wed, 2007-11-28 at 11:18 +0100, Netskin | Corin Langosch wrote: > Now I have to use a cifs mounted maildir directory and found it to be > quite slow, > though I already tuned it a lot. The only way to get it fast was to put > INDEX and > CONTROL files on the local disc and so outside of the maildirs. > Performance is > great but the problem is with submissions to maildirs. > > When a CONTROL directive is given, dovecot writes the submissions file to > this directory too. Now as I have two dovecots in a loadbalancer my > users have > to do their modifications to their subscriptions always twice (for each > server > in the loadbalancer). Control directory must be shared. Otherwise you'll end up breaking IMAP clients' local caches and causing all kinds of problems, because message UIDs keep changing. signature.asc Description: This is a digitally signed message part
[Dovecot] IMAP --> Creating Folders --> trailing slash
Hello List, i use Dovecot 1.0.7 for pop and imap on Suse Linux 10.1. I need a little help in understanding something. If i want to create a folder with outlook express or thunderbird which can also create subfolders, then i have to create these folders with a trailing slash. folders created with trailing slash are in filesystem created als real folders, "normal" folders are created as file. Is it possible to change this behavior? I want to create a folders just by typing a name without trailing slash. It should be possible to store messages in this folder or create subfolders. Is there any workaround to achieve this goal? Thank you Andre
[Dovecot] little submissions feature request
Hi! I'm using dovecot for a while now and really like it. Actually dovecot 1.5 on Debian AMD64. Now I have to use a cifs mounted maildir directory and found it to be quite slow, though I already tuned it a lot. The only way to get it fast was to put INDEX and CONTROL files on the local disc and so outside of the maildirs. Performance is great but the problem is with submissions to maildirs. When a CONTROL directive is given, dovecot writes the submissions file to this directory too. Now as I have two dovecots in a loadbalancer my users have to do their modifications to their subscriptions always twice (for each server in the loadbalancer). I now modified dovecot on my own to put the submissions file into the Maildir, everything else is unchanged. This works just great and as desired. Anything I missed in my setup, locking issues, ...? Otherwise it may worth adding a switch for this? A directive like INDEX, CONTROL... :SUBMISSSIONS=path... Regards, Corin
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
On Wed, 2007-11-28 at 09:10 +0100, Mark Heitmann wrote: > pollsys(0x08099448, 11, 0x08047B10, 0x) = 1 > fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 > fd=7 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 > fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN|POLLPRI Looks like this is the problem. fd=1 should /dev/null and it should never be passed to poll(). I'll try to look more into this later today. signature.asc Description: This is a digitally signed message part
[Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
Mark Heitmann wrote: >>/ >>/ Did you compile with Solaris's own LDAP library or with OpenLDAP? />>/ />/ I'm using iPlanet DS and Solaris's LDAP library. />>/ / />>/ People have had different kinds of problems with Solaris LDAP />>/ library. You could try if OpenLDAP works better. />/ />/ I have the same problem also with openLDAP (compiled with gcc 3.4.3 on />/ Solaris 10 x86 (Update 4)). When I build dovecot with ldap-support, the />/ dovecot-auth process gets 100% CPU time, without ldap-support, the />/ problem doesn't exists. />/ />/ The machine is a Sun Fire X2200 M2 with an AMD Opteron processor />/ on actual patch level. Does somebody have a solution for this problem />/ (pollsys) under Solaris 10? />/ />/ Greets, />/ Mark />/ / What does truss report the verbose arguments to pollsys to be? eg: # truss -v pollsys -p `pgrep dovecot-auth` Here is my output from truss: pollsys(0x08047780, 5, 0x08047758, 0x) = 0 fd=9 ev=POLLIN rev=0 fd=-1 ev=0 rev=0 ...last pollfd structure repeated 3 times... timeout: 0.0 sec pollsys(0x08099448, 11, 0x08047B10, 0x) = 1 fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=7 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN|POLLPRI fd=0 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=3 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=10 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=11 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=12 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=13 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=14 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=15 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 timeout: 0.47800 sec pollsys(0x08047780, 5, 0x08047758, 0x) = 0 fd=9 ev=POLLIN rev=0 fd=-1 ev=0 rev=0 ...last pollfd structure repeated 3 times... timeout: 0.0 sec pollsys(0x08099448, 11, 0x08047B10, 0x) = 1 fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=7 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN|POLLPRI fd=0 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=3 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=10 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=11 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=12 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=13 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=14 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=15 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 timeout: 0.47800 sec The timeout values in the large block change from truss-call to truss-call, the highest values are round about 2.0 sec ... but in many truss calls no times 0 (zero) seconds, just in the short block My output from dtrace: 0 61836pollsys:entry libc.so.1`__pollsys+0x7 libc.so.1`poll+0x52 libnspr4.so`_pr_poll_with_poll+0x3c1 libnspr4.so`PR_Poll+0x16 libldap.so.5`prldap_poll+0xfa libldap.so.5`nsldapi_iostatus_poll+0xbb libldap.so.5`wait4msg+0x62c libldap.so.5`nsldapi_result_nolock+0x56 libldap.so.5`ldap_result+0x94 dovecot-auth`ldap_input+0x64 0 61836pollsys:entry libc.so.1`__pollsys+0x7 libc.so.1`poll+0x52 dovecot-auth`io_loop_handler_run+0x35 dovecot-auth`io_loop_run+0x21 dovecot-auth`main+0x3fa dovecot-auth`_start+0x80 0 61836pollsys:entry libc.so.1`__pollsys+0x7 libc.so.1`poll+0x52 libnspr4.so`_pr_poll_with_poll+0x3c1 libnspr4.so`PR_Poll+0x16 libldap.so.5`prldap_poll+0xfa libldap.so.5`nsldapi_iostatus_poll+0xbb libldap.so.5`wait4msg+0x62c libldap.so.5`nsldapi_result_nolock+0x56 libldap.so.5`ldap_result+0x94 dovecot-auth`ldap_input+0x64 0 61836pollsys:entry libc.so.1`__pollsys+0x7 libc.so.1`poll+0x52 dovecot-auth`io_loop_handler_run+0x35 dovecot-auth`io_loop_run+0x21 dovecot-auth`main+0x3fa dovecot-auth`_start+0x80 Mark
