Tickets :: Comment on [#12129] Sieve example config does not work with Dovecot 2.1.15

* Your Email Address
* Spam protection	Enter the letters below: .___.___..___.. ..__. [__ \| \| \ /[__] \| \| \| \/ \| \|
Comment	>>> Solution: additional directive in backends.local.php >>> >>> $backends['sieve']['hordeauth'] = true; >> >> I don't know which version of Ingo you're using, but in the latest >> stable version from pear, I can't find any references to 'hordeauth', > > Version I'm using is 3.0.1 as stated above. I arrived at this > solution by a lot of googling and looking over the code. Whether it > makes sense or not, it works. > >> so the above doesn't make sense to me. Admittedly, older versions did >> use this, but this is no longer the case per the comments in >> 'ingo/config/backends.php': >> >> * NOTE: By default, the transport driver will use Horde credentials to >> * authenticate to the backend. If a different username/password is >> * needed, use the 'transport_auth' hook (see hooks.php) to define >> * these values. >> > That extract is unchanged from 3.0.1 to 3.0.3 (I assume this is what > you have). There are no changes between these versions of > backends.php related to hordeauth or anything related. In other > words, nothing "on paper" to indicate changes to this file's usage > that may occur (implemented elsewhere in the code) between versions. > >>> If I understand correctly the current state of play (based on the >>> sources, some admittedly probably outdated, that I've found while >>> researching this), and based on what I've observed above, it appears >>> that either the hordeauth param or a case-suitable entry in >>> hooks.local.php is required or timsieved driver will do nothing at >>> all. >> >> The below are the contents of my 'ingo/config/backends.local.php', >> which is working fine with Dovecot 2.1: >> >> <?php >> $backends['imap']['disabled'] = true; >> $backends['sieve']['disabled'] = false; >> $backends['sieve']['params']['usetls'] = false; >> $backends['sieve']['scriptparams']['utf8'] = true; > > If all that's required is an upgrade then great, but I'm not in a > position to do that on a whim with this server, and nothing in this > file or elsewhere indicated that that would help; if I'd thought > otherwise, I'd certainly have tried upgrading before filing this > ticket. > > I'll now schedule the upgrade as soon as possible to test whether it > solves it. Am I correct, then, that hordeauth (or whatever now > performs that function) is now defaulting to supplying just > <USERNAME> instead of <USERNAME@DOMAIN>? (The link that provided the > clue to my fix indicated that this was its effect, with the default > value being 'full' which appends the domain to the username.)
Attachment
Watch this ticket

Saved Queries