Sieve can't find Extprograms or Extdata
Hi, On a new install-from-source with Dovecot 2.2.16rc1, Piegeonhole 0.4.6 and a grab of the newest Extdata code, I confirmed basic Sieve functionality is working (made a simple sieve script with a test on message subject resulting in a fileinto action). But I cannot get Sieve to see Extdata or Extprograms. sievec reports Warning: sieve: ignored unknown extension 'vnd.dovecot.filter' while configuring available extensions and the same for vnd.dovecot.extdata. And of course for the user script, error: require command: unknown Sieve capability `vnd.dovecot.filter' (same with extdata) I'm pretty sure this is a library path problem, but I've tried symlinking and restarting dovecot with as many iterations of library paths as I can think of but still same problem. The lib90_sieve_extdata_plugin.so and lib90_sieve_extprograms_plugin.so are in /usr/local/lib/dovecot/sieve and all the rest of the normal dovecot libraries are one level above in /usr/local/lib/dovecot. I tried creating symlinks for a modules directory and a modules/sieve directory, I tried symlinking these two librarie files themselves into the top level dovecot library directory, and a few other ideas, but no luck. Is there a way I can tell where Sieve expects its libraries to reside? To see where it is looking? I didn't provide any arguments to the configure command for pigeonhole as well as extdata and it seems like the libs got placed somewhere sensible, but I don't know what else to do.
Expunge messages older than
Hi, I am using Dovecot 2.2.13 on cPanel server. Is there a way to delete messages older than some date for a number of users (in every subfolder)? Thank you
Re: Expunge messages older than
On 03/07/2015 01:20 PM, absolutely_f...@libero.it wrote: Hi, I am using Dovecot 2.2.13 on cPanel server. Is there a way to delete messages older than some date for a number of users (in every subfolder)? Thank you http://wiki2.dovecot.org/Plugins/Expire
Re: v2.2.16 release candidate released
On 06 Mar 2015, at 21:58, Daniel Miller dmil...@amfes.com wrote: On 3/6/2015 7:53 AM, Timo Sirainen wrote: http://dovecot.org/releases/2.2/rc/dovecot-2.2.16.rc1.tar.gz http://dovecot.org/releases/2.2/rc/dovecot-2.2.16.rc1.tar.gz.sig Looks like it's been a long time since v2.2.15. There have been a ton of changes since it was released though, so here's a release candidate first to find out if somebody can find any bugs before the final v2.2.16. Unfortunately I haven't had time/energy to read Dovecot mailing list for a while now. I'm hoping this will change, but I don't really expect it to happen anytime soon. On the positive side for Dovecot, it's now becoming used in more and more multi-million user installations, which brings all kinds of nice new improvements. Great to hear both Dovecot and you are doing well. I do need to ask you to check the list for two threads: mdbox attachment errors Rebuilding SIS attachment links from log A few of us have been having SIS problems. Unless there's a way to reproduce a bug I don't think I can do anything about it (I could spend hours looking at the code or trying to reproduce it and come up with nothing). But a while ago I did think about a SIS redesign that would make it much less likely to break - just need to get it actually implemented: Currently single instance storage works by having one global directory that contains all the attachments. They are hashed by the attachment content, so for example /var/attachments/ac/7d/ac7d1274891248912489124 would be the attachment. Then each instance would have its own hard link to it, e.g. /var/attachments/ac/7d/hashes/ac7d1274891248912489124-1234567890. sdbox and mdbox can use these by containing the ac7d1274891248912489124-1234567890 in the header metadata. When mail is deleted, the hard link is deleted. If the link count had been 2, the original attachment file was deleted also. (There's of course some race conditions here, but in those rare situations the attachment would just be duplicated, which isn't too bad.) The main problem with the old design is that all the users' attachments are dumped into a single global directory. It's difficult to take backups and in general it seems too difficult to manage correctly so I haven't really recommended using it in any bigger installations. So here's the new idea, which is nearly the same as the old, but with a small change that makes it much nicer I think: Instead of storing the attachment hard links to a global dir, store the hard links under the user's mail dir. This way taking backups doesn't require anything complicated, just tar the user's mail dir. You can rm -rf the user without forever leaving the user's attachments lying around in the global dir (assuming there's a job that periodically cleans out attachments with link count=1). In general there's no easy way to accidentally break things. The only new complication here is that if users are split to multiple filesystems, hard linking across them isn't going to work. So this would then require not only having a per-user mail directory but also per-user attachment directory (which would actually be the per-filesystem attachment dir). The SIS is implemented as lib-fs backend wrapper, so a new one could be implemented easily without breaking the old one.
Outlook 2013/2010 nightmare
Hi All,
This is my first post so forgive me if this hits the wrong list.
I have been using dovecot for years happily with SendMail on mainly
CentOS servers, and my customers are starting to more and more use
Thunderbird, so my perfect model is:
Linux -- Dovecot -- SendMail -- Thunderbird (or mobile phone e-mail app).
I do have some customers using Outlook or Windows Live Mail, and these
are for the most part working fine with IMAP - I don't do POP.
My mod to the dovecot.conf file:
disable_plaintext_auth=no
My mod to conf.d/10-mail.conf:
#mail_location =
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u
My mod to conf.d/10-master.conf:
#default_internal_user = dovecot
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imap_second {
port = 10143
}
inet_listener imaps {
#port = 993
#ssl = yes
}
- I do the 10143 bit so I can pseudo hide port 143 for clients with
devices that access both internally and externally - port forwarded on
MikroTik routers for my customers.
All goes well for many years with the above configs, and continues to be
awesome as always.
Under the user's ${HOME} directory they end up with a lovely 'mail'
directory and all of the e-mail client folders live in harmony under there.
This weekend I am helping a customer cut over his customer from legacy
POP based e-mail uses with splatterings of Outlook 2010 and 2013
throughout the company, to using Linux with IMAP in the setup as
described above as per my standard configs.
The issue starts when you add an IMAP user to the Outlook client and
upon opening it, initially, it tries to find a Sent Items folder under
IMAP to send from. To this end I have traditionally gone into the
dialogue box that opens, click on the IMAP account to receive a list of
possible folders, but it now immediately crashes indicating Outlook has
had an error, and it all goes to hell from there. Outlook then cannot
open but keeps crashing with its unknown error.
Up to last week at another site with Windows Live Mail, this was not an
issue.
By modifying the e-mail account via Control Panel, I can delete or
modify the account and try again.
Here is what I found:
If I don't specify a 'root' folder under the Advanced tab which also
contains the port selections for 143 and 25, it fails.
If I follow the MS recommended root folder example from Microsoft and
use INBOX, or Inbox, it 'does' stop the error but you can't create
subfolders - I am assuming as this is picking up the .imap/INBOX folder
or something and makes sense that it can't create folders under
INBOX/Inbox, particularly if this is a file rather than a directory that
dovecot/Outlook are pointing to.
What I have found is I can 'lie' to Outlook and put in a 'mail' folder.
This results in a ${HOME}/login_name/mail/mail folder, but I don't care,
as it happily puts files under mail/mail.
Now here is something totally strange: If I try to put this same account
on another PC so users can 'share' the same e-mail account, even with my
'mail' root folder work-around, it crashes again.
All through this, Thuderbird works fine and so does RoundCube - SOGo
will be up and working a bit later once I get the initial part up and
going... but I digress but good to know it is only Outlook doing this.
To share multiple accounts I am currently getting the subsequent PCs
that need to share a universal account to select a root folder mail2,
mail3 etc. I then delete these folders and symbolic link the mail2,
mail3 etc to the mail directory - yucky fix, but kind of works with some
auto scripting of .subscriptions to follow so all of the Outlook clients
sync to the one 'real' root folder.
I have never seen this before and have customers running all kinds of
IMAP e-mail clients to dovecot on Linux.
I saw an MS posted bug on something for IMAP and they recommend rolling
back MS updates to fix it - but I am not sure the client can or will do
that.
This kind of random issue that only affects this site at present is why
I only recommend people use e-mail clients like Thunderbird because it
just 'works'. The users at this site would not switch and will cite they
have been working in a POP situation on their other Linux box since Adam
was a boy.
Any help would be very much appreciated.
I like to think I can do this with my eyes shut by now, but this one has
got me stumped.
--
As always, I remain at your service.
Kindest Regards,
David.M.Clark (Director - Senior Linux/UNIX Consultant)
=--=
Davrom Consulting Pty LtdE-mail : da...@davrom.com
PO Box 1644, Sunnybank Hills, 4109 Twitter: @DavidClark1961
ABN: 81 096 990 804 MSN: da...@davrom.com
Phone/Fax: 61-7-32720267 Skype: dmc1961
Mobile: 0418-763124 Google: dmc1...@gmail.com
Podcast:
