Re: btrfs for mail_attachment_dir

2015-02-25 Thread Marc Stürmer

Am 25.02.2015 um 12:24 schrieb Hardy Flor:


I don't find  any indication, that no btrfs for then filesystem for the
path in "mail_attachment_dir" is to be used. but btrfs has a big problem
with hard links in the same directory.
Nuisance is the only deal with a different file system?


Btrfs is still nowhere near production ready in 2015. If you want to run 
a server, which should be reliable, use ext4 oder maybe XFS instead. Or 
ZFS, if you need a COW.


If you are feeling adventurous, then use btrfs.


Re: Mail migration / dsync

2015-02-25 Thread Casey Stone
I'm not an expert, but I just gave a similar answer to someone else in a 
similar situation (significantly older dovecot version on old server) and I 
suggest trying to use doveadm backup on the new server to pull the mail from 
the old server via IMAP like:

doveadm -o imapc_features=fetch-headers -o mail_prefetch_count=20 -o 
imapc_port=993 -o imapc_ssl=imaps -o imapc_ssl_verify=no -o mail_fsync=never -o 
imapc_host=mail.example.com -o imapc_user=mailu...@exmple.com -o 
imapc_password=123456 backup -R imapc:


Re: dsync backup touch source index files.

2015-02-25 Thread Casey Stone
I don't know the answer to your question, but in case you don't get a suitable 
answer from someone better qualified than me, you might try having dovadm pull 
the data my making an imap connection to the older server like:

doveadm -o imapc_features=fetch-headers -o mail_prefetch_count=20 -o 
imapc_port=993 -o imapc_ssl=imaps -o imapc_ssl_verify=no -o mail_fsync=never -o 
imapc_host=mail.example.com -o imapc_user=mailu...@exmple.com -o 
imapc_password=123456 backup -R imapc:


New maildir default permissions

2015-02-25 Thread Jan Krcmar
hi,

i'm trying to configure dovecot to create maildir directories of new
users with specific permissions. i'm ending with this

dovecot: auth: Debug: sql(blabla,::1,): query: SELECT
data_user.username, data_user.password, 500 AS userdb_uid, 500 AS
userdb_gid, 500 as mail_access_groups, 750 as mode, '/var/mail/' AS
userdb_home, concat('maildir:/var/mail/', data_ldap.maildir) AS
userdb_mail, concat('*:bytes=', data_ldap.quota) AS userdb_quota_rule
FROM data_user LEFT JOIN data_ldap ON data_user.ldap_id=data_ldap.id
WHERE lower(username) = 'blabla' AND active=true
dovecot: auth: Debug: client passdb out:
OK#0111#011user=blabla#011mail_access_groups=500#011mode=750
dovecot: auth: Debug: master in: REQUEST#0111075576833#0115939#0111#.
dovecot: auth: Debug: prefetch(blabla,::1,): success
dovecot: auth: Debug: master userdb out:
USER#0111075576833#011blabla#011uid=500#011gid=500#011home=/var/mail/#011mail=maildir:/var/mail/b/blabla#011quota_rule=*:bytes=100M
dovecot: imap-login: Login: user=, method=PLAIN, rip=::1,
lip=::1, mpid=5940, secured, session=
dovecot: imap: Debug: Loading modules from directory: /usr/lib/dovecot/modules
dovecot: imap: Debug: Module loaded:
/usr/lib/dovecot/modules/lib10_quota_plugin.so
dovecot: imap: Debug: Module loaded:
/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so
dovecot: imap: Debug: Added userdb setting: mail=maildir:/var/mail/b/blabla
dovecot: imap: Debug: Added userdb setting: plugin/quota_rule=*:bytes=100M
dovecot: imap(blabla): Debug: Effective uid=500, gid=500, home=/var/mail/
dovecot: imap(blabla): Debug: Quota root: name=User quota backend=maildir args=
dovecot: imap(blabla): Debug: Quota rule: root=User quota mailbox=*
bytes=104857600 messages=0
dovecot: imap(blabla): Debug: Namespace inbox: type=private, prefix=,
sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes
location=maildir:/var/mail/b/blabla
dovecot: imap(blabla): Debug: maildir++: root=/var/mail/b/blabla,
index=, control=, inbox=/var/mail/b/blabla, alt=
dovecot: imap(blabla): Debug: Namespace : /var/mail/b/blabla doesn't
exist yet, using default permissions
dovecot: imap(blabla): Debug: Namespace : Using permissions from
/var/mail/b/blabla: mode=0700 gid=-1

could anyone tell me, how to set the default permissions? it uses
mode=700, and i need mode=750 instead

i'm using dovecot 2.1.17

thanks
fous


dsync backup touch source index files.

2015-02-25 Thread Anton Chevychalov
Hi everyone,

Can someone explain me why dsync need read-write access to source box when 
pulling data (dsync -R backup)? 

I am working on migration from Dovecot 1.x with maildir to latest
Dovecot 2.2.15 with mdbox and found that there is no way to do this
from ro filesystem (got "failed: Read-only file system" on access
to /dovecot.index.log).

I am wondering is it bug or feature? 

I am not sure that this is save to allow dsync v2.2.15 to have write access to 
v1.x indexes.

-- 
Anton Chevychalov


Proxying of non "plain" SASL mechnisms.

2015-02-25 Thread Peter Mogensen
Hi,

I understand from earlier discussions that the reason dovecot doesn't
support proxying of other SASL mechanisms than those which supply the
plaintext password is that in general it would be possible to proxy any
SASL mechanism since it might protect against man-in-the-middle attacks
(which would prevent proxying).

However, that has led to choice between letting users use PLAIN (or
equivalent), or to have the proxy access the target hosts by "master"
password.
Of course, having the plaintext password the proxy could in principle do
other challenge/response SASL handshakes with the target backend, but
right now only LOGIN and PLAIN is implemented.

So I wondered about the rationale for not just forward the SASL
handshake.
- First, blindly forwardning will not do, since the mech data has to be
decoded anyway to do any per/user passdb lookup (to, say, find the
target host). But you don't need authentication to actually succeed to
do that. You only need AuthZ-id or AuthN-id.

- Secondly, the design of the interaction between imap-login processes
and the auth-service in general prevent in general to forward
multi-handshake SASL mechanisms, since the authentication must be done
before the proxying can be started. But it doesn't prevent forwarding of
single handshake SASL mechanisms which use SASL-IR.

- Thirdly, while it's correct that some SASL mechanisms protect against
man-in-the-middle attacks, that doesn't apply for most single-handshake
SASL-IR mechanisms unless they do some kind of channel-binding. (like
SASL EXTERNAL)
For example, the GS2-KRB5 SASL mech would be perfectly forwarded if just
the Kerberos ticket doesn't put restrictions on the client IP-address.

So, why not just extend the support for proxy authentication forwarding
to any single-handskake SASL-IR mechanism, which doesn't use
channel-binding? (which includes PLAIN, but also GS2-KRB5, and possibly
others).

/Peter


ACL Error

2015-02-25 Thread Bobber

I'm trying to set up global ACLs.  I have the following in the config file:


# acl
mail_plugins = acl

protocol imap {
  mail_plugins = $mail_plugins imap_acl
}

plugin {
  # Without global ACLs:
  #acl = vfile

  # With global ACL files in /etc/dovecot/dovecot-acls file (v2.2.11+):
  #acl = vfile:/etc/dovecot/dovecot-acl
  acl = vfile:/usr/local/etc/dovecot/dovecot-acl
}


And here is my dovecot-acl:


user=bobber lrwstipekxa
authenticated lr



But when I restart dovecot and try to access folders, I get the 
following errors in the log file:


Error: Global ACL file /usr/local/etc/dovecot/dovecot-acl line 1: 
Unknown ID 'lrwstipekxa'


Any ideas what's causing this?

--
*Bob Wooldridge*
Blog: http://kc0dxf.net/blog/


Re: btrfs for mail_attachment_dir

2015-02-25 Thread Hardy Flor

I have posted this in the German-debian forum:

https://debianforum.de/forum/viewtopic.php?f=9&t=154096


The result was that it still does not work. I have the kernel with 
version 3.13.33



According to [0] (and the links in there), this problem has been long 
solved.


[0]http://en.wikipedia.org/wiki/Btrfs#File_system_tree



Re: btrfs for mail_attachment_dir

2015-02-25 Thread Eduardo M KALINOWSKI

On Qua, 25 Fev 2015, Hardy Flor wrote:
I don't find  any indication, that no btrfs for then filesystem for  
the path in "mail_attachment_dir" is to be used. but btrfs has a big  
problem with hard links in the same directory.


According to [0] (and the links in there), this problem has been long solved.

[0]http://en.wikipedia.org/wiki/Btrfs#File_system_tree

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br


Re: "Temporary authentication failure" ? Cant connect with ldap user

2015-02-25 Thread Steffen Kaiser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 25 Feb 2015, Mihai Badici wrote:

On Wednesday 25 February 2015 10:31:22 David Scheele wrote:

Is there a good, foolproof dovecot-openldap tutorial that walks you through
the steps and works with the newest version of both softwares?
I'm giving up and starting anew.



2015-02-24 11:33 GMT+01:00 Mihai Badici :

On Tuesday 24 February 2015 10:51:44 David Scheele wrote:

Hmm...


Well, I'm not sure.  As I said, you can take a look on my templates.
Openldap is maybe to flexible for us :) and the dovecot setup always depend
on openldap setup.. which depend on your distribution if you install it with
apt-get.
If you download my packages you don't need to install them but there are some
configuration templates you can see and modify.

If you have anonymous access you don't need to bind with admin credentials.


(Y)

@David:
You should know your LDAP setup and craft Dovecot for it.

- From your question I guess that you have not changed the LDAP scheme, but 
use some default posixAccount objectclass.


So tell us:

1) does ldapsearch -x -h server
displays all users ? If yes: No admin access required.

2) How does your users are to login? Mail address, account name, user 
name?


3) Which information is storred in LDAP per account mandatory and in which 
LDAP attribute.



*ldapsearch -x cn=admin* gives me:
| # A bunch of information not really interesting
| # search result
| search: 2
| result: 32 No such object
|
| numResponses: 1

*ldapsearch -x cn=admin* gives the same.
Did i configure the ldap wrong?


Ldapsearch will search in the default container.
But probably the admin user is in different container, like
cn=admin,cn=config
so you can't find it with this search




- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBVO27x3z1H7kL/d9rAQJGhggAj/DEzn5pl9yGG2tgAo2OvMCAW9ag/saw
D+vDNK2MKgDRYbWk3Rt9pdHGWmTBtXMZltIX/EFe/nFOMMBFpwS0qbEaJedCuNad
ThEVtrYRkliwkXR6XMdLbPWbM47eJt+feftygD/NJ6V5rZ6QmX22aALJbZz8QbRJ
9nq7CsbGai1T99cjUxBny2u6jF96gjXI4DIr8iyva+GIWiehIGUl4n+9NGqgvvky
SBLwefTrRZDQPfMj4+NjNxdjZ/RDKC+aFVSTrbybXQCTUv3LDm9BU5JJchO6q53x
VzJWLmC08gmuv0bG+xc5rmoeV49GoFhkX1C8h5ovDbG5XYbPiP9pQA==
=Z1Ak
-END PGP SIGNATURE-


btrfs for mail_attachment_dir

2015-02-25 Thread Hardy Flor

Hello,

I don't find  any indication, that no btrfs for then filesystem for the 
path in "mail_attachment_dir" is to be used. but btrfs has a big problem 
with hard links in the same directory.

Nuisance is the only deal with a different file system?

Hardy


Re: "Temporary authentication failure" ? Cant connect with ldap user

2015-02-25 Thread Mihai Badici
On Wednesday 25 February 2015 10:31:22 David Scheele wrote:
> Is there a good, foolproof dovecot-openldap tutorial that walks you through
> the steps and works with the newest version of both softwares?
> I'm giving up and starting anew.

> 2015-02-24 11:33 GMT+01:00 Mihai Badici :
> > On Tuesday 24 February 2015 10:51:44 David Scheele wrote:
> > > Hmm...



Well, I'm not sure.  As I said, you can take a look on my templates.
Openldap is maybe to flexible for us :) and the dovecot setup always depend 
on openldap setup.. which depend on your distribution if you install it with 
apt-get.
If you download my packages you don't need to install them but there are some 
configuration templates you can see and modify.

If you have anonymous access you don't need to bind with admin credentials.



> > > *ldapsearch -x cn=admin* gives me:
> > > | # A bunch of information not really interesting
> > > | # search result
> > > | search: 2
> > > | result: 32 No such object
> > > | 
> > > | numResponses: 1
> > > 
> > > *ldapsearch -x cn=admin* gives the same.
> > > Did i configure the ldap wrong?
> > 
> > Ldapsearch will search in the default container.
> > But probably the admin user is in different container, like
> > cn=admin,cn=config
> > so you can't find it with this search
-- 
Mihai Bădici
http://mihai.badici.ro


Re: "Temporary authentication failure" ? Cant connect with ldap user

2015-02-25 Thread David Scheele
Is there a good, foolproof dovecot-openldap tutorial that walks you through
the steps and works with the newest version of both softwares?
I'm giving up and starting anew.

2015-02-24 11:33 GMT+01:00 Mihai Badici :

> On Tuesday 24 February 2015 10:51:44 David Scheele wrote:
> > Hmm...
> >
> > *ldapsearch -x cn=admin* gives me:
> > | # A bunch of information not really interesting
> > | # search result
> > | search: 2
> > | result: 32 No such object
> > |
> > | numResponses: 1
> >
> > *ldapsearch -x cn=admin* gives the same.
> > Did i configure the ldap wrong?
> Ldapsearch will search in the default container.
> But probably the admin user is in different container, like
> cn=admin,cn=config
> so you can't find it with this search
>


Metadata suport for public mailboxes

2015-02-25 Thread Sergio Talens-Oliag
I'm using the latest version of dovecot (2.2.15) and I was trying to use a
public namespace with metadata; I've found that it works for the users with
enough permissions to set the metadata, but the values are set per user, that
is, each user has its own metadata and does not see the values set by others.

That sounds OK, as my mail_attribute_dict is configured as follows:

  mail_attribute_dict = file:/srv/vmail/%d/spool/%n/dovecot-metadata

But for public mailboxes it would make sense to set the metadata in a user
independent mode.

Searching around I've found the following on the dovecot changelog:

  2013-11-02  Timo Sirainen  
[...]
TODO:
- Metadata doesn't work for public namespaces. There should probably
  be a mail_attribute_public_dict setting for that.
[...]

So my guess that the mail_attribute_public_dict is not available.

Is that the case or has it been implemented in a different way?

Thanks in advance,

  Sergio

-- 
Sergio Talens-Oliag
Key fingerprint = FF77 A16B 9D09 FC7B 6656 CFAD 261D E19A 578A 36F2