On 12/15/2009 10:48 PM, Pascal Volk wrote:

There were a few API changes in the past. My ManageSieve installation is working so far. The necessary modifications are attached as patch. (But remember: There is no guarantee …)

Thanks a lot Pascal for sharing the patch. I don't expect guarantees.

I patched and compiled fine, then added

protocols = ... managesieve

and

service managesieve { inet_listener { port = 2000 } }

service managesieve{ }

to dovecot.conf and master.conf respectively.

Seems to work, but complains after login about not finding the active script.

dovecot: managesieve(someuser): sieve-storage: Active sieve script symlink /home/someuser/.dovecot.sieve is broken: invalid/unknown path to storage (points to /somepath/user/sieve/.dovecot.sieve.sieve).

But the script seems to be there as expected. Have you encountered anything ilike this in your setup?

thanks again

Luca

On Wed, 2009-12-16 at 05:01 +0100, Pascal Volk wrote:

...

service managesieve { inet_listener { port = 2000 } }

Are you sure? Or was it: 'service managesieve-login {…}'?

Right, stupid typo, in the config is obviously correct.

BTW: Use port 4190 http://www.iana.org/assignments/port-numbers: (last updated 2009-12-15) … sieve 4190/tcp ManageSieve Protocol

Oh, great. Changed.

...

service managesieve{ }

This is optional.

Thanks, I've moved it out.

No, I've seen nothing like that. Additional to your above mentioned settings I've got this settings:

# plugin.conf plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve # some none sieve related settings }

Yes, me too:

plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve sieve_extensions = +notify +imapflags }

Your userdb returns a home value? I'm asking because one time /home/someuser and the other one /somepath/user.

mail_location = maildir:/somepath/%u

...

userdb { args = blocking=yes driver = passwd }

I added blocking right now because I just realized users are in LDAP.

/home/someuser/.dovecot.sieve is a symlink to /somepath/user/.dovecot.sieve.sieve

By the way, I just reloaded dovecot with the few changes highligthed in this mail and it does not give the error I described...

I could also alter my filters from Horde Ingo, but strangely enough it won't display the currently active script and managesieve does not log anything anymore about the sieve script not being there.

I tried adding a new sieve fileinto rule, which works. Sent a test mail which would match the filter and dovecot also logged this

Dec 17 20:45:35 someserver dovecot: lda(someuser): rename(/somepath/someuser/dovecot-uidvalidity, /somepath/someuser/luca/dovecot-uidvalidity) failed: No such file or directory

But now both sieve and managesieve seem to work.

thanks for your time

Luca

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 17-12-2009 21:21, Luca Corti wrote:

On Thu, 2009-12-17 at 20:56 +0100, Luca Corti wrote:

...

I could also alter my filters from Horde Ingo, but strangely enough it won't display the currently active script and managesieve does not log anything anymore about the sieve script not being there.

Ignore this one, it's an issue with Ingo apparently. Still wondering what fixed the symlink error though.

thanks

Luca

Off-topic: could you tell me how you configured Ingo to work with ManageSieve? I tried following the guide on the Horde website, but it doesn't work for me. I defined the Dovecot backend, but I don't get how I go from there. Here is the relevant part:

$backends['dovecot'] = array( 'driver' => 'timsieved', 'preferred' => 'localhost', 'hordeauth' => true, 'params' => array( // Hostname of the timsieved server 'hostspec' => 'localhost', // Login type of the server 'logintype' => 'PLAIN', // Enable/disable TLS encryption 'usetls' => true, // Port number of the timsieved server 'port' => 2000, // Name of the sieve script 'scriptname' => 'ingo', // The following settings can be used to specify an administration // user to update all users' scripts. If you want to use an admin // user, you also need to disable 'hordeauth' above. You have to use // an admin user if you want to use shared rules. // 'username' => 'cyrus', // 'password' => '*****', ), 'script' => 'sieve', 'scriptparams' => array(), 'shares' => false );

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksqmrgACgkQkPq5zKsAFijYLwCfbWlYo6atN4Xa2cZdtRiAwU6b hiYAnjZZALPlzZWOfbZqgvs5eyGg/qYd =JuTV -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 17-12-2009 22:02, Luca Corti wrote:

On Thu, 2009-12-17 at 21:55 +0100, Nick Douma wrote:

...

    // Name of the sieve script
    'scriptname' => 'ingo',

'scriptname' => '.dovecot.sieve',

Everything else seems good to me.

ciao

Luca

Ok, but how do I tell ingo to use this backend? I can't find a config entry of something in the Horde Administration panels that seem to control this. Also, when I click filters, I don't see my already present Sieve filters. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksqn1AACgkQkPq5zKsAFijgxwCfQI/FkKpqa/H8PztAxiJ+oAaK R+MAn2oyQHHi1y3EjGrVIVLfp2rS9kEC =qkvj -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 17-12-2009 23:06, Luca Corti wrote:

On Thu, 2009-12-17 at 22:14 +0100, Nick Douma wrote:

...

Ok, but how do I tell ingo to use this backend? I can't find a config entry of something in the Horde Administration panels that seem to control this. Also, when I click filters, I don't see my already present Sieve filters.

Just leave only that backend uncommented in backends.php

Actually, I figured it out. I needed to set the 'preferred' setting to the right hostname. In my case it was the web address of the server that Horde runs on (mail.domain.tld) instead of localhost or just domain.tld. Now it works like a charm. Thanks for the help. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksqrC0ACgkQkPq5zKsAFijLOgCggJpuFl8Qs1pzFHUyB3i8Iehj N1wAoI03a5qteghwcvtWkzrjT8VBiw4h =xlUn -----END PGP SIGNATURE-----

On Tue, 2009-12-15 at 14:01 -0800, ben@electricembers.net wrote:

We are using the quota plugin and storing people's usage in the (mysql) db.

We have some users that have some mail, but are not really receiving new mail, nor are they logging in to check mail, so they don't yet have a row in the quota table.

Is there a way to cause dovecot to just generate that quota usage?

Not currently. But you could log in as the users and issue GETQUOTAROOT INBOX command. (If you don't know their passwords, you could enable master user logins.)

On Wed, 2009-12-16 at 00:03 +0000, Ed W wrote:

On 14/12/2009 03:12, Timo Sirainen wrote:

...

Largest changes since alpha3:

• if some IP address is failing authentications, all auth attempts from the IP are delayed increasingly. a successful auth drops the delay. max delay is 15 seconds. this is enforced by auth process, so it works across different connections/processes/protocols.

I have a bunch of users behind several NATs (wifi hotspots, dialup gateways) and it would seem that if some muppet innocently sets up the wrong username/password then all the other users get significantly penalised? (I have even seen cases people have a go at configuring Outlook, it doesn't work and they just leave it misconfigured and sending incorrect passwords forever afterwards...)

This could be a problem, yes.. I probably have to make this configurable in some way. Or perhaps I could add some more code so that if only the same user+password combination (or a few of them) are the problem, it doesn't penalize. This feels familiar, I think I almost started coding that before. Or it's as if I already did, but I don't see the code..

When that's done, once in a while when an invalid user+pass combo happens it delays the next user's login for a couple of seconds, but then it would get cached for some time so if it tries again there would be no delays.

Also in any case, even if I don't change it from how it works now, the penalty goes away immediately after first successful login. So pretty much the worst that can happen is that innocent users have to wait for 15 seconds before they can log in.

Should it not only delay *incorrect* logins? ie each time you get it wrong then you get a penalty (which increases). Getting it right would login instantly and slightly decrease the "got it wrong" penalty (or perhaps it just time ages)?

That would also make the penalty pretty pointless. Attackers would just login, wait for half a second, assume it was a failed login, disconnect and connect again.