Re: Released Pigeonhole v0.4.10 for Dovecot v2.2.21
Op 12/14/2015 om 1:13 AM schreef Stephan Bosch: > Hello Dovecot users, > > I got a bit stalled by our recent switch to Git, but here is the final > v0.4.10 release of Pigeonhole for Dovecot v2.2.21. Nothing of > consequence changed since the last RC. > > Changelog v0.4.10: > > + Implemented the Sieve mime and foreverypart extensions (RFC 5703). > These are fully implemented. The interaction with the editheader > extension needs some work, but this should not influence most uses; > i.e., changes by the editheader extension are not always visible > using foreverypart/mime. > + Sieve body extension: Properly implemented the `:text' body > transform. It now extracts text for HTML message parts. > + Sieve enotify extension: mailto method: Implemented the > sieve_notify_mailto_envelope_from setting. This allows configuring > the source of the notification sender address for e-mail > notifications. This is similar to what already can be configured for > redirect. > + Added a sieve_enabled (defaults to 'yes') setting that allows > explicitly disabling Sieve processing for particular users. This used > to be possible by setting `sieve=', but ever since the sieve_before, > sieve_after and sieve_default settings were added, this method was > not reliable anymore. > - variables extension: Fixed handling of empty string by the `:length' > set modifier. An empty string yielded an empty string rather than "0". > - Fixed memory leak in the Sieve script byte code dumping facility. > Extension contexts were never actually freed. > - Fixed handling of implicit keep when the last Sieve script is a > global one. In that case the implicit keep action was executed in > global context, which could mean that trivial (quota) errors ended up > in the system log file, rather than the user log file. > - doveadm sieve plugin: Fixed crashes caused by incorrect context > allocation in the sieve command implementations. > > The release is available as follows: > > http://pigeonhole.dovecot.org/releases/2.2/rc/dovecot-2.2-pigeonhole-0.4.10.tar.gz > http://pigeonhole.dovecot.org/releases/2.2/rc/dovecot-2.2-pigeonhole-0.4.10.tar.gz.sig Oops: http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.10.tar.gz http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.10.tar.gz.sig Regards, Stephan.
Re: Released Pigeonhole v0.4.10 for Dovecot v2.2.21
On 2015-12-14 01:13:41 +0100, Stephan Bosch wrote: > The release is available as follows: > > http://pigeonhole.dovecot.org/releases/2.2/rc/dovecot-2.2-pigeonhole-0.4.10.tar.gz > http://pigeonhole.dovecot.org/releases/2.2/rc/dovecot-2.2-pigeonhole-0.4.10.tar.gz.sig working links are http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.10.tar.gz http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.10.tar.gz.sig hth darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Released Pigeonhole v0.4.10 for Dovecot v2.2.21
Hello Dovecot users, I got a bit stalled by our recent switch to Git, but here is the final v0.4.10 release of Pigeonhole for Dovecot v2.2.21. Nothing of consequence changed since the last RC. Changelog v0.4.10: + Implemented the Sieve mime and foreverypart extensions (RFC 5703). These are fully implemented. The interaction with the editheader extension needs some work, but this should not influence most uses; i.e., changes by the editheader extension are not always visible using foreverypart/mime. + Sieve body extension: Properly implemented the `:text' body transform. It now extracts text for HTML message parts. + Sieve enotify extension: mailto method: Implemented the sieve_notify_mailto_envelope_from setting. This allows configuring the source of the notification sender address for e-mail notifications. This is similar to what already can be configured for redirect. + Added a sieve_enabled (defaults to 'yes') setting that allows explicitly disabling Sieve processing for particular users. This used to be possible by setting `sieve=', but ever since the sieve_before, sieve_after and sieve_default settings were added, this method was not reliable anymore. - variables extension: Fixed handling of empty string by the `:length' set modifier. An empty string yielded an empty string rather than "0". - Fixed memory leak in the Sieve script byte code dumping facility. Extension contexts were never actually freed. - Fixed handling of implicit keep when the last Sieve script is a global one. In that case the implicit keep action was executed in global context, which could mean that trivial (quota) errors ended up in the system log file, rather than the user log file. - doveadm sieve plugin: Fixed crashes caused by incorrect context allocation in the sieve command implementations. The release is available as follows: http://pigeonhole.dovecot.org/releases/2.2/rc/dovecot-2.2-pigeonhole-0.4.10.tar.gz http://pigeonhole.dovecot.org/releases/2.2/rc/dovecot-2.2-pigeonhole-0.4.10.tar.gz.sig Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch step...@rename-it.nl
Re: Dovecot code repository moved to Github (Xi fixed)
Op 12/10/2015 om 1:07 AM schreef Stephan Bosch: > Op 12/9/2015 om 5:44 PM schreef Stephan Bosch: >> >> Op 9-12-2015 om 17:32 schreef Timo Sirainen: >>> http://hg.dovecot.org/ is no longer being updated. The public >>> repository exists now in https://github.com/dovecot/core instead. >>> >>> I'm not sure yet if we should continue pushing commit emails to >>> dovecot-cvs list or if Github's internal notifications are enough. In >>> any case dovecot-cvs list isn't working right now. >> Oh, that means that Xi packages aren't updated with Dovecot changes at >> the moment. >> >> Will fix... > OK, Xi now successfully re-builds packages from GitHub (Pigeonhole is > still on Hg). I haven't tested what happens when Timo commits new > changes, but I can fix any problems pretty quickly. Problems will > probably surface anyway. Just mail me if you notice any problems. > > BTW, Xi now also (slowly) builds armhf packages for Debian Jessie. Xi currently won't notice new releases. It will produce commits on the master branch as v2.2.20 updates for the time being. I will fix this in the near future. Regards, Stephan.
Re: v2.2.21 released
On 13.12.2015 20:35, Timo Sirainen wrote: On 13 Dec 2015, at 15:40, Gerhard Wiesinger wrote: On 11.12.2015 18:10, Timo Sirainen wrote: http://dovecot.org/releases/2.2/dovecot-2.2.21.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.21.tar.gz.sig Hello Timo, tried to compile it, but tests fail on Fedora 23 with latest gcc (gcc-5.3.1-2.fc23.x86_64): The compiling works, the make check part just fails. You could also set NOVALGRIND=1 environment before building and it would succeed. ==11141== Conditional jump or move depends on uninitialised value(s) ==11141==at 0x512C753: icu_54::LocaleUtility::initLocaleFromName(icu_54::UnicodeString const&, icu_54::Locale&) (in /usr/lib64/libicuuc.so.54.1) ==11141==by 0x4DB1E70: icu_54::TransliteratorSpec::TransliteratorSpec(icu_54::UnicodeString const&) (in /usr/lib64/libicui18n.so.54.1) This looks a bit worrysome though. But if it's a bug then I'm pretty sure it's on the libicu side. I'm not sure what exactly is wrong in there. You could also see if setting LC_ALL=C environment happens to work. What's the libicu version? 54.1? libicu-devel-54.1-5.fc23.x86_64 libicu-54.1-5.fc23.x86_64 gcc has been recentyl updated to 5.3.1 (from 5.1.1 as far as I remember). So all the libs are compiled with the old version. Maybe there is some incompatibility. Will try that. Ciao, Gerhard
Re: v2.2.21 released
On 13 Dec 2015, at 15:40, Gerhard Wiesinger wrote: > > On 11.12.2015 18:10, Timo Sirainen wrote: >> http://dovecot.org/releases/2.2/dovecot-2.2.21.tar.gz >> http://dovecot.org/releases/2.2/dovecot-2.2.21.tar.gz.sig >> > > Hello Timo, > > tried to compile it, but tests fail on Fedora 23 with latest gcc > (gcc-5.3.1-2.fc23.x86_64): The compiling works, the make check part just fails. You could also set NOVALGRIND=1 environment before building and it would succeed. > ==11141== Conditional jump or move depends on uninitialised value(s) > ==11141==at 0x512C753: > icu_54::LocaleUtility::initLocaleFromName(icu_54::UnicodeString const&, > icu_54::Locale&) (in /usr/lib64/libicuuc.so.54.1) > ==11141==by 0x4DB1E70: > icu_54::TransliteratorSpec::TransliteratorSpec(icu_54::UnicodeString const&) > (in /usr/lib64/libicui18n.so.54.1) This looks a bit worrysome though. But if it's a bug then I'm pretty sure it's on the libicu side. I'm not sure what exactly is wrong in there. You could also see if setting LC_ALL=C environment happens to work. What's the libicu version? 54.1?
Re: 2.2.21: doveadm expunge is broken
> On 13 Dec 2015, at 19:56, Alexander Moisseev wrote: > > # doveadm expunge -u u...@example.com MAILBOX Trash ALL > Fatal: expunge: To avoid accidents, each branch in search query must contain > something else besides MAILBOX (e.g. just add "all" if you want everything) Fixed: https://github.com/dovecot/core/commit/6971937a6f3e93844dbd43bdbe903628e21a9422 Also as workaround you can use 1:* instead of ALL.
2.2.21: doveadm expunge is broken
# doveadm expunge -u u...@example.com MAILBOX Trash ALL Fatal: expunge: To avoid accidents, each branch in search query must contain something else besides MAILBOX (e.g. just add "all" if you want everything) -- Alexander
Dovecot SASL and GSSAPI (IPA)
Hi Everyone, I'm currently using dovecot SASL in postfix and passwd-file in dovecot for authenticating my users. I want to switch to using IPA instead. I have both the postfix (mailman01) and dovecot (mailman02) servers joined to the IPA domain. I have GSSAPI working in dovecot for IMAP. But, the SASL GSSAPI authentication in postfix fails with this error: warning: unknown[10.200.5.100]: SASL GSSAPI authentication failed: This is what dovecot logs: Dec 12 22:31:54 mailman02 dovecot: auth: Debug: auth client connected (pid=0) Dec 12 22:31:54 mailman02 dovecot: auth: Debug: client in: AUTH 1 GSSAPI service=smtpnologin lip=10.200.9.14 rip=10.200.5.100secured resp= Dec 12 22:31:54 mailman02 dovecot: auth: Debug: gssapi(?,10.200.5.100): Obtaining credentials for s...@mailman02.theinside.rnr Dec 12 22:31:54 mailman02 dovecot: auth: gssapi(?,10.200.5.100): While processing incoming data: Unspecified GSS failure. Minor code may provide more information Dec 12 22:31:54 mailman02 dovecot: auth: gssapi(?,10.200.5.100): While processing incoming data: Wrong principal in request Dec 12 22:31:56 mailman02 dovecot: auth: Debug: client passdb out: FAIL 1 I've tried changing the "smtpd_sasl_local_domain" in postfix's main.cf file to "mailman02.theinside.rnr", but I get the same errors in dovecot and postfix. Right now the config in postfix looks like this: import_environment="KRB5_KTNAME=/etc/postfix/smtp.keytab" smtpd_sasl_local_domain = mailman01.theoutside.rnr Does what I'm trying to do make sense? If so, how do I fix it? Do I have to stop using dovecot sasl in postfix and switch to cyrus sasl? -- Ranbir
Re: v2.2.21 released
On 11.12.2015 18:10, Timo Sirainen wrote: http://dovecot.org/releases/2.2/dovecot-2.2.21.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.21.tar.gz.sig Hello Timo, tried to compile it, but tests fail on Fedora 23 with latest gcc (gcc-5.3.1-2.fc23.x86_64): fts_icu_utf8_to_utf16 ascii resize ... : ok fts_icu_utf8_to_utf16 32bit resize ... : ok fts_icu_utf16_to_utf8 : ok fts_icu_utf16_to_utf8 resize . : ok fts_icu_translate : ok fts_icu_translate_resize resize .. : ok fts_icu_lcase : ok fts_icu_lcase resize . : ok 0 / 8 tests failed ==11141== Conditional jump or move depends on uninitialised value(s) ==11141==at 0x512C753: icu_54::LocaleUtility::initLocaleFromName(icu_54::UnicodeString const&, icu_54::Locale&) (in /usr/lib64/libicuuc.so.54.1) ==11141==by 0x4DB1E70: icu_54::TransliteratorSpec::TransliteratorSpec(icu_54::UnicodeString const&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DB28D4: icu_54::TransliteratorRegistry::find(icu_54::UnicodeString&, icu_54::UnicodeString&, icu_54::UnicodeString&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DB2B76: icu_54::TransliteratorRegistry::find(icu_54::UnicodeString const&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DB2BFA: icu_54::TransliteratorRegistry::get(icu_54::UnicodeString const&, icu_54::TransliteratorAlias*&, UErrorCode&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4D9D58D: icu_54::Transliterator::createBasicInstance(icu_54::UnicodeString const&, icu_54::UnicodeString const*) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DA3DEC: icu_54::TransliteratorIDParser::SingleID::createInstance() (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DA432B: icu_54::TransliteratorIDParser::instantiateList(icu_54::UVector&, UErrorCode&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4D9E9DA: icu_54::Transliterator::createInstance(icu_54::UnicodeString const&, UTransDirection, UParseError&, UErrorCode&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4D9F6E9: utrans_openU_54 (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x10B9F5: get_translit (test-fts-icu.c:90) ==11141==by 0x10BBFC: test_fts_icu_translate (test-fts-icu.c:106) ==11141== ==11141== Conditional jump or move depends on uninitialised value(s) ==11141==at 0x512C753: icu_54::LocaleUtility::initLocaleFromName(icu_54::UnicodeString const&, icu_54::Locale&) (in /usr/lib64/libicuuc.so.54.1) ==11141==by 0x4DB1E70: icu_54::TransliteratorSpec::TransliteratorSpec(icu_54::UnicodeString const&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DB28DF: icu_54::TransliteratorRegistry::find(icu_54::UnicodeString&, icu_54::UnicodeString&, icu_54::UnicodeString&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DB2B76: icu_54::TransliteratorRegistry::find(icu_54::UnicodeString const&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DB2BFA: icu_54::TransliteratorRegistry::get(icu_54::UnicodeString const&, icu_54::TransliteratorAlias*&, UErrorCode&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4D9D58D: icu_54::Transliterator::createBasicInstance(icu_54::UnicodeString const&, icu_54::UnicodeString const*) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DA3DEC: icu_54::TransliteratorIDParser::SingleID::createInstance() (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4DA432B: icu_54::TransliteratorIDParser::instantiateList(icu_54::UVector&, UErrorCode&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4D9E9DA: icu_54::Transliterator::createInstance(icu_54::UnicodeString const&, UTransDirection, UParseError&, UErrorCode&) (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x4D9F6E9: utrans_openU_54 (in /usr/lib64/libicui18n.so.54.1) ==11141==by 0x10B9F5: get_translit (test-fts-icu.c:90) ==11141==by 0x10BBFC: test_fts_icu_translate (test-fts-icu.c:106) ==11141== Failed to run: ./test-fts-icu Any ideas? Thank you. Ciao, Gerhard
Re: 2.2.21: panic in stats-plugin.c: line 324 (stats_user_deinit): assertion failed: (stats_global_user == user)
On 13 Dec 2015, at 03:53, Jakub Jankowski wrote: > > Hi, > > I've just upgraded dovecot to 2.2.21 (from 2.2.18), and I'm getting a crash > when doing dsync backup: > > $ dsync -v -u u...@domain.com backup > maildir:/backup/maildirs/domain.com/user/Maildir > dsync(u...@domain.com): Panic: file stats-plugin.c: line 324 > (stats_user_deinit): assertion failed: (stats_global_user == user) Fixed: https://github.com/dovecot/core/commit/3a719a01a1790df053854d5245ace5ab6d0c3d13 A workaround is to just disable stats plugin with dsync. It didn't work in earlier versions anyway. The crash only came because it now started working, except for this crash at deinit.
System-user-controllable custom passwords and mail locations
Hello everyone, I'd like to set up dovecot so that it uses the standard system accounts, but with different passwords specific to email. Seems like a fairly common setup, but the catch is, I want the users to be able to set their passwords themselves, without needing any assistance from a server administrator. I'm wondering what's the easiest way of implementing this. From what I've understood, this requirement would probably rule out a separate passwd-file (since the standard Linux passwd doesn't seem to support using a custom passwd file), SQL, flat-file dict, and Redis (since you can't give users access only to their row, or dict key; it's either the entire database (or flat file), or nothing). (Of course, I could work around that limitation by writing a C program that I would install as SUID root, which would only change the invoking user's password, but I'd prefer not to start dumping arbitrary SUID binaries all over the place.) So, that would probably only leave me with LDAP, checkpassword, and the FS dict backend. I can imagine how I could get LDAP to do this -- add some extra attribute for each user, and put together a simple script to change passwords, say, in Python, that would bind as the user and write the new password. However, this would require me to store the system user account database in LDAP, which is kind of overkill on at least one of the servers I want this setup on, where I know for certain that there won't ever be more than a handful of users. Checkpassword would probably work, too; perhaps by looking into some file in the user's $HOME or such. I'm not entirely certain about the security, or performance implications of that approach. With the FS dict backend, I could probably point it to a directory, in which every user would own a file containing their password, that no one else could write to. I haven't been able to find any more details about the structure of this directory hierarchy, though, or the contents of the individual files, so I don't know whether this is a viable approach, or not. My questions are, then: Is there some other way of implementing separate passwords that the users can set themselves that I'm overlooking? Is one of the three approaches described above a bad idea for some reason I don't see? Is there some kind of “standard solution” to this problem? The other thing I wanted to ask about is marginally related; I'd like to be able to allow users to customize the layout in which they store their mail. For instance, some users like to have their INBOX as an mbox in /var/mail, and other maildirs in ~/Maildirs/, others prefer having everything as a mix maildirs and mboxes in ~/mail, etc. Looking at the MailLocation wiki page, it seems like the only option, if I want to customize the location per user, is to set it in the userdb, but since we only have system users everywhere, it seems we have to use the passwd userdb, which doesn't support this kind of per-user customization (even on servers where PAM/NSS are configured to use LDAP). Again, am I overlooking something here? Is there nothing similar to ~/.imaprc, which is supported by certain versions of some other IMAP servers? Thanks in advance for any insights, Michal signature.asc Description: Digital signature
