Re: [Dovecot] delete messages after sa-learn
Florian Effenberger flo...@gmail.com wrote: I am looking for a command-line utility to automatically purge one Maildir folder. I want to periodically run sa-learn from cron, and after the spam learning folder has been added to the Bayes database, its contents should be deleted. I've searched a bit, but only found a few old utilities or some telnet+expect scripts, which both didn't look too reliable. Is there any command-line utility to delete all contents of a Maildir folder, or is there any other solution? Have you considered fetching from dovecot (maildir) to mbox file and learning from mbox file? a) fetchmail CAN use .../dovecot/imap wrapper script in plugin option to read maildir directly [set environment variable MAIL to maildir:~/Maildir in the wrapper] b) fetchmail CAN use procmail in mda option to deliver directly to mbox -- [plen: Andrew] Andrzej Adam Filip : a...@onet.eu I am a friend of the working man, and I would rather be his friend than be one. -- Clarence Darrow
Re: [Dovecot] Over quota
On Jueves 27 Mayo 2010 18:30:41 James Devine escribió: Is there any way to still be able to login/delete email via dovecot-imap when the user's filesystem quota is exceeded? We just moved from courier where this was still possible but now a user over quota can login but cannot get a list of messages and the logs show this: Move the indexes to a filesystem without quotas. Something like mail_location = maildir:~/Maildir:INDEX=/var/dovecot/%u will do the trick. HTH -- Joseba Torre. Vicegerencia de TICs, área de Explotación
Re: [Dovecot] delete messages after sa-learn
Hi Andrzej, 2010/5/28 Andrzej Adam Filip a...@onet.eu: Have you considered fetching from dovecot (maildir) to mbox file and learning from mbox file? a) fetchmail CAN use .../dovecot/imap wrapper script in plugin option to read maildir directly [set environment variable MAIL to maildir:~/Maildir in the wrapper] b) fetchmail CAN use procmail in mda option to deliver directly to mbox does fetching to mbox file bring any advantage? It seems that learning out of maildir and rm'ing afterwards works like a charm, so I guess fetchmail would bring more overhead? Florian
[Dovecot] cur folder e-mails are not shown...
Hi All! I realized that I have only e-mails from last 13 days. I see that I have lots more in the cur folder inside my Maildir folder. The problem is that I cannot see them. Permissions seems to be right: drwx-- 2 gaguilar gaguilar 1081344 2010-05-28 12:53 cur -rw--- 1 gaguilar gaguilar 4798145 2010-05-28 12:52 deliver.info -rw--- 1 gaguilar gaguilar 0 2010-04-17 21:17 deliver.log -rw--- 1 gaguilar gaguilar 191344 2010-05-28 12:51 dovecot.index -rw--- 1 gaguilar gaguilar 708608 2010-05-28 12:52 dovecot.index.cache -rw--- 1 gaguilar gaguilar 26356 2010-05-28 12:53 dovecot.index.log -rw--- 1 gaguilar gaguilar 35 2010-04-24 19:57 dovecot-keywords -rw--- 1 gaguilar gaguilar 746874 2010-05-28 12:52 dovecot-uidlist -rw--- 1 gaguilar gaguilar 8 2010-05-28 12:46 dovecot-uidvalidity -rw--- 1 gaguilar gaguilar 0 2010-04-17 00:45 dovecot-uidvalidity.4bc8e88d drwx-- 2 gaguilar gaguilar 32768 2010-05-28 12:52 new -rw--- 1 gaguilar gaguilar 2742243 2010-05-28 12:52 procmail.log -rw--- 1 gaguilar gaguilar 48 2010-05-28 12:46 subscriptions drwx-- 2 gaguilar gaguilar4096 2010-05-28 12:52 tmp dovecot --version 1.1.11 What can be the problem?
Re: [Dovecot] delete messages after sa-learn
Florian Effenberger flo...@gmail.com wrote: Hi Andrzej, 2010/5/28 Andrzej Adam Filip a...@onet.eu: Have you considered fetching from dovecot (maildir) to mbox file and learning from mbox file? a) fetchmail CAN use .../dovecot/imap wrapper script in plugin option to read maildir directly [set environment variable MAIL to maildir:~/Maildir in the wrapper] b) fetchmail CAN use procmail in mda option to deliver directly to mbox does fetching to mbox file bring any advantage? It seems that learning out of maildir and rm'ing afterwards works like a charm, so I guess fetchmail would bring more overhead? It will bring more overhead but some people value portable solutions. Some people try to avoid locking THEMSELVES into a) specific format of IMAP folder As I understand dovecot recommends switching from maildir to dbox b) specific software (specific IMAP server) I do not plan to change dovecot but I do like to keep my options open. Anyway: instead of scanning all and deleting files in maildir (race risk) you may consider moving files to another file directory/folder (on the same file-system) and learn from it. You may ask Timo How to lock maildir message/file before moving it out/deleting it by non dovecot software :-) -- [plen: Andrew] Andrzej Adam Filip : a...@onet.eu Never tell people how to do things. Tell them WHAT to do and they will surprise you with their ingenuity. -- Gen. George S. Patton, Jr.
Re: [Dovecot] Problems with Outlook clients after a migration
Some new data: If I remember correctly, I've changed: - commented out the outlook-idle workaround. - the server's iptables now doesn't use state in 993 port and the situation is much better. I've got some Disconnected in IDLE messages, but must of them where related to changes in the client (twice thunderbird dying, and once a system being suspended). There're still some from one of the most problematic clients (windows 7 + outlook 2007) with no apparent reason, but the user didn't sensed anything. I'll keep my test for some days before the final migration, but now it seems ok. -- Joseba Torre. Vicegerencia de TICs, área de Explotación
Re: [Dovecot] recipient_delimiter
On 2010-05-27 1:42 PM, Phil Howard wrote: Yup, there was a 2nd setting nearly at the bottom of the file, and it was different. Thanks for catching that. This is why you *always* go by what output pof postconf -n says, not what you think you put in main.cf. You wasted a lot of time (yours and others here) on that unnecessarily... -- Best regards, Charles
[Dovecot] Auto Block!
There is an plugin that makes dovecot lock an imap/pop/smtpauth if the user miss passowrd more than N times ? I would like to avoid brute force! Thanks []'sf.rique
Re: [Dovecot] Auto Block!
On 28/05/10 16:14, Henrique Fernandes wrote: There is an plugin that makes dovecot lock an imap/pop/smtpauth if the user miss passowrd more than N times ? I would like to avoid brute force! Thanks []'sf.rique Hi, Take a look at fail2ban + iptables. Regards, Tom
Re: [Dovecot] Auto Block!
On 5/28/2010 10:20 AM, Tom Hendrikx wrote: On 28/05/10 16:14, Henrique Fernandes wrote: There is an plugin that makes dovecot lock an imap/pop/smtpauth if the user miss passowrd more than N times ? I would like to avoid brute force! Thanks []'sf.rique Hi, Take a look at fail2ban + iptables. Regards, Tom http://wiki.dovecot.org/HowTo/Fail2Ban M.A.
Re: [Dovecot] Auto Block!
I had seen this before! But i thought would be better if dovecot had it built in! But Thansk anyway! []'sf.rique On Fri, May 28, 2010 at 11:28 AM, Mario Antonio supp...@webjogger.netwrote: On 5/28/2010 10:20 AM, Tom Hendrikx wrote: On 28/05/10 16:14, Henrique Fernandes wrote: There is an plugin that makes dovecot lock an imap/pop/smtpauth if the user miss passowrd more than N times ? I would like to avoid brute force! Thanks []'sf.rique Hi, Take a look at fail2ban + iptables. Regards, Tom http://wiki.dovecot.org/HowTo/Fail2Ban M.A.
Re: [Dovecot] recipient_delimiter
On Fri, May 28, 2010 at 09:55, Charles Marcus cmar...@media-brokers.com wrote: On 2010-05-27 1:42 PM, Phil Howard wrote: Yup, there was a 2nd setting nearly at the bottom of the file, and it was different. Thanks for catching that. This is why you *always* go by what output pof postconf -n says, not what you think you put in main.cf. You wasted a lot of time (yours and others here) on that unnecessarily... My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of what else is needed). What might be needed to avoid things like this is something to compare them. Or maybe postfix giving an error when a conflicting setting is encountered (or is there some basis for always allowing settings that change previous settings).
Re: [Dovecot] cur folder e-mails are not shown...
On Fri, 2010-05-28 at 12:55 +0200, Gonzalo Aguilar Delgado wrote: I realized that I have only e-mails from last 13 days. I see that I have lots more in the cur folder inside my Maildir folder. Check how many messages you have by talking IMAP protocol directly: http://wiki.dovecot.org/TestInstallation After selecting INBOX, see what x fetch 1:* (uid flags internaldate) says.
Re: [Dovecot] question about rpc quota reporting 1.2.11
On Thu, 2010-05-27 at 09:10 -0700, Tom Lieuallen wrote: I'm getting the same type of error with the quota2 line now: open(/nfs/rack/u4/quotas) failed: Permission denied Since the home directory quota worked without the plugin configuration, my guess is that the plugin config is not using rpc. I can't find any way to force it to use rpc. Again, if I make that 'quotas' file world readable (which I believe isn't good practice), dovecot stops complaining. Dovecot first finds the mountpoint and then gets its filesystem. If it's nfs, it uses rquota, otherwise local quota. You could enable mail_debug=yes and see what mountpoints Dovecot finds and then see if their type is nfs or something else. Also this would make checking the type (correctly) even easier: http://hg.dovecot.org/dovecot-1.2/rev/eaba4cfeaa44
Re: [Dovecot] 1.2.11, mbox, new mail
On Thu, 2010-05-27 at 20:14 -0500, Stan Hoeppner wrote: What, if anything, am I sacrificing, or what new problems might I cause, by using mbox_very_dirty_syncs=yes?Previously I was using mbox_dirty_syncs = yes. If non-Dovecot MUAs modify mbox simultaneously (except appends by MDA are ok), Dovecot might not notice those changes immediately and it might log some errors sometimes.
Re: [Dovecot] Dovecot and Apples Mail.app
On Thu, 2010-05-27 at 10:17 +0200, Gerhard Waldemair wrote: Now I have the problem, that I get mail under Mail.app double. (same header, Message-ID ,...) When I use Thudnerbird under MacOS there is all OK. That doesn't make any sense. Only thing I can think of is that you created two identical accounts to Mail.app.. Are there some Configs that I need to make for MacOS / Mail.app ? No.
Re: [Dovecot] cur folder e-mails are not shown...
On Fri, 2010-05-28 at 12:55 +0200, Gonzalo Aguilar Delgado wrote:
I realized that I have only e-mails from last 13 days. I see that I have
lots more in the cur folder inside my Maildir folder.
The problem is that I cannot see them.
What can be the problem?
Since you didn't claim you actually are missing mail, just seeing more
on the IMAP server than in your client...
They could be deleted (actually marked for deletion, physically
removed upon expunge). Those would have a T flag in the file name after
the comma. Your MUA Evolution shows them in the Trash (virtual) folder.
They could have been flagged Junk, and only be displayed in the Junk
(virtual) folder.
You could have a search active, hiding some mail.
You could have specifically hidden them. See the View menu.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] recipient_delimiter
On Fri, 28 May 2010 11:25:17 -0400 Phil Howard ttip...@gmail.com articulated: My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of what else is needed). What might be needed to avoid things like this is something to compare them. Or maybe postfix giving an error when a conflicting setting is encountered (or is there some basis for always allowing settings that change previous settings). In the Postfix main.cf file, the last entry wins. This is one of the reasons to use postconf -n and NOT what you think the correct entry is. The output of postconf -n shows what Postfix sees. To sum it up: Provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger. If the problem is SASL related, consider including the output from the saslfinger tool. This can be found at http://postfix.state-of-mind.de/patrick.koetter/saslfinger/. If the problem is about too much mail in the queue, consider including output from the qshape tool, as described in the QSHAPE_README file. If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document. -- Jerry dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: [Dovecot] recipient_delimiter
On Fri, May 28, 2010 at 12:11, Jerry dovecot.u...@seibercom.net wrote: On Fri, 28 May 2010 11:25:17 -0400 Phil Howard ttip...@gmail.com articulated: My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of what else is needed). What might be needed to avoid things like this is something to compare them. Or maybe postfix giving an error when a conflicting setting is encountered (or is there some basis for always allowing settings that change previous settings). In the Postfix main.cf file, the last entry wins. This is one of the reasons to use postconf -n and NOT what you think the correct entry is. The output of postconf -n shows what Postfix sees. To sum it up: Provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger. If the problem is SASL related, consider including the output from the saslfinger tool. This can be found at http://postfix.state-of-mind.de/patrick.koetter/saslfinger/. If the problem is about too much mail in the queue, consider including output from the qshape tool, as described in the QSHAPE_README file. If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document. Have you seen any config check tools?
Re: [Dovecot] recipient_delimiter
On 2010-05-28 11:25 AM, Phil Howard wrote: On Fri, May 28, 2010 at 09:55, Charles Marcus wrote: On 2010-05-27 1:42 PM, Phil Howard wrote: Yup, there was a 2nd setting nearly at the bottom of the file, and it was different. Thanks for catching that. This is why you *always* go by what output pof postconf -n says, not what you think you put in main.cf. You wasted a lot of time (yours and others here) on that unnecessarily... My main.cf file has the comments (my own that explains why settings are there, not the default comments). It is the easier to read file. Yes, but you are missing the point - the output of postconf -n shows *exactly* what postfix is *using*, *not* what you *think* it is using because you *misread* (ie, missed the last recipient_delimiter entry that was different from the one you were changing). It can also demonstrate that you aren't using the main.cf (or dovecot.conf) file that you thought you were using due to running something chroot'd when you didn't realize it, or packaging errors by your package maintainer, etc, etc, etc... Even then, I was also reading the postconf -n output and just didn't see the subtle difference (I was thinking more along the lines of what else is needed). Right - you weren't using the output as intended. -- Best regards, Charles
Re: [Dovecot] recipient_delimiter
On 2010-05-28 1:00 PM, Phil Howard wrote: If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document. Have you seen any config check tools? Yes - it's called a brain. ;) Seriously - only you know your environment well enough to evaluate any given config. Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output. -- Best regards, Charles
Re: [Dovecot] purge maildir folder after sa-learn
On Wed, May 26, 2010 at 06:13, Timo Sirainen t...@iki.fi wrote: On Wed, 2010-05-26 at 09:56 +0200, Florian Effenberger wrote: rm -f /path/to/Maildir/.spam-learn/* Oh, I really ment .spam-learn/cur/* (and maybe .spam-learn/new/* if you make it learn from both and it doesn't move mails to cur/). Can I simply delete the files, don't I destroy any indices or slow down Dovecot operation because of index rebuilding? Keep Dovecot's index files around so that they won't get deleted while Dovecot is trying to read/write them. You won't slow down anything by manually deleting maildir files. So basically, just moving mail files out (to a learn queue or whatever), from either new or cur is safe for Dovecot? That would be simpler.
Re: [Dovecot] recipient_delimiter
On Fri, May 28, 2010 at 14:06, Charles Marcus cmar...@media-brokers.com wrote: On 2010-05-28 1:00 PM, Phil Howard wrote: If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document. Have you seen any config check tools? Yes - it's called a brain. ;) I think you are missing the point. A config check tool would be sifting through the details of the main.cf file, and the postconf-n.out file, and reporting the difference between what one thinks they have configured and what Postfix understands the configuration to be. Seriously - only you know your environment well enough to evaluate any given config. I think you are missing the point. Since what Postfix uses as the configuration isn't guaranteed to be what is coded ... because config items do get changed by subsequent config items ... a tool that can compare things comes in valuable. We all know that doing things in less time is a good thing (or else there would be not complaint about wasting time). But manually sifting through two files, point by point, and cross checking everything, every time, is as much, or more, of a time waster. And given that it would be done quite often, one is wasting a lot of time if they carry out that process. This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that. Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output. But it doesn't complain for conflict errors. And that was the class of error that happened.
Re: [Dovecot] recipient_delimiter
On Fri, 28 May 2010 14:18:06 -0400 Phil Howard ttip...@gmail.com articulated: On Fri, May 28, 2010 at 14:06, Charles Marcus cmar...@media-brokers.com wrote: On 2010-05-28 1:00 PM, Phil Howard wrote: If the problem is protocol related (connections time out, or an SMTP server complains about syntax errors etc.) consider recording a session with tcpdump, as described in the DEBUG_README document. Have you seen any config check tools? Yes - it's called a brain. ;) I think you are missing the point. A config check tool would be sifting through the details of the main.cf file, and the postconf-n.out file, and reporting the difference between what one thinks they have configured and what Postfix understands the configuration to be. You are missing the point. Postfix sees what the output of postfix -d displays unless modified. Those modifications are what postfix -n displays. This is not taking into consideration any modifications done in master.cf obviously. Seriously - only you know your environment well enough to evaluate any given config. I think you are missing the point. Since what Postfix uses as the configuration isn't guaranteed to be what is coded ... Scratching Head If you configured it, Postfix will either use it or log an error regarding it. That I can guarantee (Been there before) because config items do get changed by subsequent config items ... a tool that can compare things comes in valuable. We all know that doing things in less time is a good thing (or else there would be not complaint about wasting time). But manually sifting through two files, point by point, and cross checking everything, every time, is as much, or more, of a time waster. And given that it would be done quite often, one is wasting a lot of time if they carry out that process. Exactly what type of system are you trying to support? I fail to understand why you are constantly changing the base Postfix configuration. I add/delete users on a virtually daily basis, however, once my basic Postifx configuration was setup, I have had no reason to mess with it. If you are modifying it on a daily basis, you are probably doing something wrong. This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that. Correct, you can only have the last one (Postfix). I am not sure about Dovecot. Then again, I don't enter rules haphazardly. Again, the output of postconf -n is what Postfix sees and understands. If you think you have duplicate values in the file, try 'grep' to locate them. It doesn't make any difference though since the last one wins no matter what. NOTE: One known exception is: dovecot_destination_recipient_limit = 1 This does not display with postconf -n. Wietse once explained why; however, I don't remember why any more. By the way, if you are doing virtual delivery with Postfix/Dovecot, you should probably have that in the main.cf file. As always, YMMV. Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output. But it doesn't complain for conflict errors. And that was the class of error that happened. What conflict error? It would not happen in Postfix's main.cf file. -- Jerry dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: [Dovecot] recipient_delimiter
On 2010-05-28 2:18 PM, Phil Howard wrote: On Fri, May 28, 2010 at 14:06, Charles Marcus wrote: On 2010-05-28 1:00 PM, Phil Howard wrote: Have you seen any config check tools? Yes - it's called a brain. ;) I think you are missing the point. Not... A config check tool would be sifting through the details of the main.cf file, and the postconf-n.out file, and reporting the difference between what one thinks they have configured and what Postfix understands the configuration to be. ??? Again, that's what your *brain* is for. There is no program capable of reading one's mind, or ascertaining details of your environment and/or system requirements. Seriously - only you know your environment well enough to evaluate any given config. I think you are missing the point. Not... Since what Postfix uses as the configuration isn't guaranteed to be what is coded ... Sure it is... because config items do get changed by subsequent config items ... ??? Not sure what you mean by that. If the same setting is defined multiple times in main.cf, the last one wins. That is well documented. a tool that can compare things comes in valuable. It depends, but yes, some brains are valuable. We all know that doing things in less time is a good thing (or else there would be not complaint about wasting time). But manually sifting through two files, point by point, and cross checking everything, every time, is as much, or more, of a time waster. What 2 files? I thought we were talking about ,ain.cf/postconf -n output? And given that it would be done quite often, one is wasting a lot of time if they carry out that process. This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), That describes postconf to a 't'... :) and just produce the warnings ... hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that. Nope... it is enough to know that if a setting is defined twice, the last one wins. If you define a setting, and postconf -n output doesn't show what you expect, then the very first thing to do is grep main/cf for that term to see if it in there more than once. The second thing to do is make sure you're editing the right main.cf file. Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output. But it doesn't complain for conflict errors. And that was the class of error that happened. It isn't *supposed* to complain - the *documented* behavior is that the last value wins. This in fact makes customizing settings easy (at least for me). I just put all of my settings at the end of the file, so I know that those will be the ones used regardless of what is specified above. -- Best regards, Charles
Re: [Dovecot] recipient_delimiter
On Fri, May 28, 2010 at 15:28, Jerry dovecot.u...@seibercom.net wrote: Exactly what type of system are you trying to support? I fail to understand why you are constantly changing the base Postfix configuration. I add/delete users on a virtually daily basis, however, once my basic Postifx configuration was setup, I have had no reason to mess with it. If you are modifying it on a daily basis, you are probably doing something wrong. One that is just getting started. I expect to get to a point where I don't need to modify it. Not there, yet. We needed to get going on this sooner than originally planned, so not everything is in place, yet. For example, spam and virus trapping are still to do (next [*]). And tweaks are still possible for things like file locations as automation processes are added (later). I bet you have those thing already in place and thus don't need to change it. [*] Still trying to figure out how to make SpamAssassin put what it thinks is spam into an incoming spam box, rather than the usual INBOX (also seeking to find what name of such a box most people use). And that's in addition to another mailbox which users will move spam to, that comes into their INBOX, to be extracted at the server for training. This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that. Correct, you can only have the last one (Postfix). I am not sure about Dovecot. Then again, I don't enter rules haphazardly. Dovecot has sections and can do multiple sections. This is the Dovecot mailing list so you can ask about it here. Again, the output of postconf -n is what Postfix sees and understands. If you think you have duplicate values in the file, try 'grep' to locate them. It doesn't make any difference though since the last one wins no matter what. NOTE: One known exception is: dovecot_destination_recipient_limit = 1 This does not display with postconf -n. Wietse once explained why; however, I don't remember why any more. By the way, if you are doing virtual delivery with Postfix/Dovecot, you should probably have that in the main.cf file. As always, YMMV. I'm assuming because it is a dynamically named setting for a transport. Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output. But it doesn't complain for conflict errors. And that was the class of error that happened. What conflict error? It would not happen in Postfix's main.cf file. Two like settings, where one would not be used, regardless of which (whether it's a first setting wins or a last setting wins system), is a conflict in my book. I'd have made the system flag it as an error (except maybe if both settings would have the exact same effect) and maybe not even start up. If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change.
Re: [Dovecot] recipient_delimiter
On 2010-05-28 4:49 PM, Phil Howard wrote: If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change. The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people). -- Best regards, Charles
Re: [Dovecot] 1.2.11, mbox, new mail
Timo Sirainen put forth on 5/28/2010 10:55 AM: On Thu, 2010-05-27 at 20:14 -0500, Stan Hoeppner wrote: What, if anything, am I sacrificing, or what new problems might I cause, by using mbox_very_dirty_syncs=yes?Previously I was using mbox_dirty_syncs = yes. If non-Dovecot MUAs modify mbox simultaneously (except appends by MDA are ok), Dovecot might not notice those changes immediately and it might log some errors sometimes. So it's the same caveat as with mbox_dirty_syncs = yes. If the caveats are the same, why do both settings exist, given that mbox_very_dirty_syncs=yes yields superior performance? Is there more potential danger with mbox_very_dirty_syncs? That was the impression I had, thus why I was using the milder setting. -- Stan
Re: [Dovecot] recipient_delimiter
On Fri, May 28, 2010 at 16:53, Charles Marcus cmar...@media-brokers.com wrote: On 2010-05-28 4:49 PM, Phil Howard wrote: If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change. The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people). So you are saying that this is not meant for people?
Re: [Dovecot] recipient_delimiter
On 2010-05-28 5:01 PM, Phil Howard wrote: On Fri, May 28, 2010 at 16:53, Charles Marcus wrote: The whole purpose of the -n output is to provide clean, easy to read *settings* as seen by postfix (as opposed to comments that are meant for people). So you are saying that this is not meant for people? sigh yeah, so I worded it badly... Of course it is meant for people, but it is meant to show only the bare minimum of what postfix sees as the settings. It is left up to you, the sys admin, to be able to interpret the data as presented, bearing in mind all caveats (ie, that last setting wins)... -- Best regards, Charles
Re: [Dovecot] recipient_delimiter
On Fri, 28 May 2010 16:26:53 -0400 Charles Marcus cmar...@media-brokers.com articulated: This in fact makes customizing settings easy (at least for me). I just put all of my settings at the end of the file, so I know that those will be the ones used regardless of what is specified above. That is exactly how I do mine also. If I ever needed to revert to a virgin config file, all I need do is either comment out or delete all of the entries I added. I have always considered Postfix's Last Wins philosophy in its config file a big +. -- Jerry dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ No matter how subtle the wizard, a knife in the shoulder blades will seriously cramp his style.
[Dovecot] Dovecot 1.2.11 driver_mysql_db error
Hi, I'm getting an error trying to make 1.2.11 with mysql drivers on. The output that I'm getting is: Undefined first referenced symbol in file driver_mysql_db ../lib-sql/libsql.a(sql-drivers-register.o) ld: fatal: Symbol referencing errors. No output written to dovecot-auth *** Error code 1 make: Fatal error: Command failed for target `dovecot-auth' Current working directory /home/src/objss9/dovecot-1.2.11/src/auth *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/src/objss9/dovecot-1.2.11/src *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/src/objss9/dovecot-1.2.11 *** Error code 1 make: Fatal error: Command failed for target `all' The same error does not come up with making 1.2.8. Don't know if this is a bug or not, but wanted to report it if it is. Thanks! * * Tom Goerger - Email/Unix System Administrator * * * * University of Minnesota Email: t...@umn.edu * * Operations, Infrastructure and Architecture Phone: 4-5804 * * Internet ServicesOffice: 626J WBOB* * * *
[Dovecot] doveadm: Error: dlopen(/path/2/lib10_doveadm_expire_plugin.so) failed
Hi Timo, dunno why, but I've executed doveadm with the -D option. Debug output contains: doveadm(root): Error: dlopen(/path/2/lib/dovecot/doveadm/lib10_doveadm_expire_plugin.so) failed: /path/2/lib/dovecot/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_lookup dovecot --version 2.0.beta5 (4faaf5b037d5) Regards, Pascal -- The trapper recommends today: 5e1f1e55.1014...@localdomain.org
