Re: Dovecot and Self-signed issue

[Michael A. Peters]

Definitely client issue, connecting via evolution works just fine.

So I suppose it is off the the thunderbird list. I like thunderbird better.

Only plugin I use is dkim validator and when I started thunderbird w/o 
extensions - still had same issue.


But I think it is definitely not a dovecot problem.

On 09/25/2017 01:49 PM, Michael A. Peters wrote:
I'm not running any A/V software, and the same version of dovecot on 
servers with CA signed certs (komodo) - the client connects to them just 
fine.


On 09/25/2017 01:40 PM, Tony wrote:

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:

I use dovecot on several servers. One of them uses a self-signed cert,
it's just me.

It worked fine until yesterday when I upgraded my desktop (NOT the
server) to CentOS 7.4

Now thunderbird complains when it starts up, and won't let me confirm
the security exception.

On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
attempts in 1 secs): user=<>,
rip=2600:1010:b064:f260:e83e:562d:2316:18df,
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca: SSL alert number 48,
session=

I believe this is a client issue, as it worked just fine in CentOS 7.3
client, but I am hoping this has been seen and fixed before.

Re: Quota - frustrated trying to configure ...

[Tony]

1. how do I keep mails from being rejected and kept in the local
mailqueue instead? (which is the old system's behavior)?

* You can set a quota grace to basically have a soft-limit - allowing the user 
to go slightly above their allocated quota.

2. what's the best (or simplest or recommended) way of setting up
per-user-quotas in this setup?

* I'm not sure if this is considered the "simplest", but like you I am also 
using LDAP auth. With this setup, I have LDAP manage per-user quotas. The 
primary mail schema I use is equipped with a mailQuota attribute. I have this 
quota attribute set as part of user_attrs in dovecot-ldap.conf.ext. For 
example, per user quotas in LDAP:

user_attrs = ,mailQuota=quota_rule=*:bytes=%$

3. how can I get  an overview/list of all users and their quota usage? (I
guess I just solved that - "doveadm quota get -A" seems to work)

* It helps to set up aliases unless you don't mind typing a lot. To get an 
overview/list of all users and their quota usage I have a couple quota aliases 
defined:

alias quotaa='doveadm quota get -A | sort -h '
$ quotaa

alias quota='doveadm quota get -u $1 '
$ quota 

IMHO the official Dovecot docs are great, but I also battled with quotas for a 
short duration, so hopefully this will help a bit more.


Cheers,
TC

On 9/25/17 11:51 AM, Garry Glendown wrote:
>
> On 25.09.2017 20:28, Sami Ketola wrote:
>>> On 25 Sep 2017, at 21.19, Garry Glendown  wrote:
>>>
>>> doveadm(root): Error: chdir(/root/) failed: Permission denied
>>> (euid=479(dovecot) egid=478(dovecot) missing +x perm: /root, dir owned
>>> by 0:0 mode=0700)
>>> doveadm(root): Error: chdir(/root) failed: Permission denied
>>>
>>> It looks like dovecot doesn't actually attempt to look at the central
>>> maildir, but instead seems to attempt to enter the current user's
>>> homedir (which, in this case, is root).
>>
>> what was the command line you used to test this? As this looks a lot like you
>> just tried to check root users quota.
> Actually no, I tried "doveadm quote recalc" without any parameters ... I
> found the command in the wiki, which - as with most other information -
> might be helpful if you already know what you are doing ...
>
> "If your quotas are out of sync, you can use doveadm quota recalc
> command to recalculate them. "
>
> I assumed it would recalculate all users' quotas ... using the -u
> argument with an account actually does seem to work, at least I do not
> get any errors. Also, the get command seems to be accurate from what I
> can tell. Further tests show that the system already checks the quota
> correctly ... and hard-rejects any mails to users with full quota ...
>
> So with that part already working, I have new problems to solve:
>
> * how do I keep mails from being rejected and kept in the local
> mailqueue instead? (which is the old system's behavior)?
> * what's the best (or simplest or recommended) way of setting up
> per-user-quotas in this setup?
> * how can I get  an overview/list of all users and their quota usage? (I
> guess I just solved that - "doveadm quota get -A" seems to work)
>
> thanks, -garry




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Dovecot and Self-signed issue

[Michael A. Peters]

I'm not running any A/V software, and the same version of dovecot on 
servers with CA signed certs (komodo) - the client connects to them just 
fine.


On 09/25/2017 01:40 PM, Tony wrote:

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:

I use dovecot on several servers. One of them uses a self-signed cert,
it's just me.

It worked fine until yesterday when I upgraded my desktop (NOT the
server) to CentOS 7.4

Now thunderbird complains when it starts up, and won't let me confirm
the security exception.

On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
attempts in 1 secs): user=<>,
rip=2600:1010:b064:f260:e83e:562d:2316:18df,
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca: SSL alert number 48,
session=

I believe this is a client issue, as it worked just fine in CentOS 7.3
client, but I am hoping this has been seen and fixed before.

Re: Dovecot and Self-signed issue

[Tony]

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:
> I use dovecot on several servers. One of them uses a self-signed cert,
> it's just me.
>
> It worked fine until yesterday when I upgraded my desktop (NOT the
> server) to CentOS 7.4
>
> Now thunderbird complains when it starts up, and won't let me confirm
> the security exception.
>
> On the server the following error occurs in the log:
>
> Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
> attempts in 1 secs): user=<>,
> rip=2600:1010:b064:f260:e83e:562d:2316:18df,
> lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
> failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
> unknown ca: SSL alert number 48,
> session=
>
> I believe this is a client issue, as it worked just fine in CentOS 7.3
> client, but I am hoping this has been seen and fixed before.

Dovecot and Self-signed issue

[Michael A. Peters]

I use dovecot on several servers. One of them uses a self-signed cert, 
it's just me.


It worked fine until yesterday when I upgraded my desktop (NOT the 
server) to CentOS 7.4


Now thunderbird complains when it starts up, and won't let me confirm 
the security exception.


On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth 
attempts in 1 secs): user=<>, 
rip=2600:1010:b064:f260:e83e:562d:2316:18df, 
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept() 
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown 
ca: SSL alert number 48, session=


I believe this is a client issue, as it worked just fine in CentOS 7.3 
client, but I am hoping this has been seen and fixed before.

Re: Quota - frustrated trying to configure ...

[Garry Glendown]

On 25.09.2017 20:28, Sami Ketola wrote:
>> On 25 Sep 2017, at 21.19, Garry Glendown  wrote:
>>
>> doveadm(root): Error: chdir(/root/) failed: Permission denied
>> (euid=479(dovecot) egid=478(dovecot) missing +x perm: /root, dir owned
>> by 0:0 mode=0700)
>> doveadm(root): Error: chdir(/root) failed: Permission denied
>>
>> It looks like dovecot doesn't actually attempt to look at the central
>> maildir, but instead seems to attempt to enter the current user's
>> homedir (which, in this case, is root).
>
>
> what was the command line you used to test this? As this looks a lot like you
> just tried to check root users quota.
Actually no, I tried "doveadm quote recalc" without any parameters ... I
found the command in the wiki, which - as with most other information -
might be helpful if you already know what you are doing ...

"If your quotas are out of sync, you can use doveadm quota recalc
command to recalculate them. "

I assumed it would recalculate all users' quotas ... using the -u
argument with an account actually does seem to work, at least I do not
get any errors. Also, the get command seems to be accurate from what I
can tell. Further tests show that the system already checks the quota
correctly ... and hard-rejects any mails to users with full quota ...

So with that part already working, I have new problems to solve:

* how do I keep mails from being rejected and kept in the local
mailqueue instead? (which is the old system's behavior)?
* what's the best (or simplest or recommended) way of setting up
per-user-quotas in this setup?
* how can I get  an overview/list of all users and their quota usage? (I
guess I just solved that - "doveadm quota get -A" seems to work)

thanks, -garry

Re: Quota - frustrated trying to configure ...

[Sami Ketola]

> On 25 Sep 2017, at 21.19, Garry Glendown  wrote:
> 
> doveadm(root): Error: chdir(/root/) failed: Permission denied
> (euid=479(dovecot) egid=478(dovecot) missing +x perm: /root, dir owned
> by 0:0 mode=0700)
> doveadm(root): Error: chdir(/root) failed: Permission denied
> 
> It looks like dovecot doesn't actually attempt to look at the central
> maildir, but instead seems to attempt to enter the current user's
> homedir (which, in this case, is root).



what was the command line you used to test this? As this looks a lot like you
just tried to check root users quota.

try: doveadm quota get -u 

and try if ‘doveadm user ’ returns any quota rules.

Sami

Quota - frustrated trying to configure ...

[Garry Glendown]

Hi,

after fighting Dovecot almost every step of the way, I have finally
gotten most of the functions configured on a customer box (used Cyrus on
a previous install, but it was dropped from SLES 12 ...)

The mail server setup uses LDAP for user authentication, has a central
maildir tree (.../dovecot/maildir//...) that is used for all
users' mail, sieve is also running well. The users themselves are just
virtual users, they do not have a local home directory or anything.

I was now trying to get Quota to work ... Looking at the Wiki more or
less showed the same "spotty" results of the rest of the Wiki. Fine for
anybody that needs the documentation just as a reference, but somewhat
lacking for someone that does not have experience in setting up Dovecot.
I tried following the wiki, as well as checking on other web pages I
came across.

In order to keep the setup simple, and not have to jump through hoops to
set up any SQL backup etc., I tried using a file-based storage of the
quota entries, as in:

dict {
    quota = file:/data/dovecot/db/quota.db
}

I also added quota entries in the other places I believe are necessary,
and set up a rule like this:

plugin {
  quota_rule = *:storage=1G
  quota_rule2 = Trash:storage=+100M
}

I got through dovecot restart without errors, and IMAP still answers.
But attempting to do a recalculation of the current quota usage ends up
with this error:

doveadm(root): Error: chdir(/root/) failed: Permission denied
(euid=479(dovecot) egid=478(dovecot) missing +x perm: /root, dir owned
by 0:0 mode=0700)
doveadm(root): Error: chdir(/root) failed: Permission denied

It looks like dovecot doesn't actually attempt to look at the central
maildir, but instead seems to attempt to enter the current user's
homedir (which, in this case, is root).

What am I (possibly) missing here? Is this way of setting it up even
viable? While I need a general per-user-quota, I also need the ability
to overwrite each user's default quota ... is there any recommendable
more detailed documentation on how to set up quota?

Thanks, -garry

Re: librmb: Mail storage on RADOS with Dovecot

[Peter Mauritius]

Hi Timo,

I am one of the authors of the software Wido announced in his mail. First, I'd 
like to say that Dovecot is a wonderful piece of software and thank you for it. 
I would like to give some explanations regarding the design we choose.

Von: Timo Sirainen 
Antworten: Dovecot Mailing List 

Datum: 24. September 2017 at 02:43:44
An: Dovecot Mailing List 
Betreff:  Re: librmb: Mail storage on RADOS with Dovecot

It would be have been nicer if RADOS support was implemented as lib-fs driver, 
and the fs-API had been used all over the place elsewhere. So 1) 
LibRadosMailBox wouldn't have been relying so much on RADOS specifically and 2) 
fs-rados could have been used for other purposes. There are already fs-dict and 
dict-fs drivers, so the RADOS dict driver may not have been necessary to 
implement if fs-rados was implemented instead (although I didn't check it 
closely enough to verify). (We've had fs-rados on our TODO list for a while 
also.)

Actually I considered using the fs-api to build a RADOS driver. But I did not 
follow that path:

The dict-fs mapping is quite simplistic. For example, I would not be able to 
use RADOS read/write operations to batch request or model the dictionary 
transactions.  Also there is no async support if you hide the RADOS dictionary 
behind as fs-api module, which would make the use of dict-rados in the 
dict-proxy harder. Doing this would help to lower the price you have to pay for 
the process model Dovecot ist using a lot.

Using a fs-rados module behing a storage module, let’s say sdbox, would IMO not 
fit to our goals. We planned to store mails in RADOS object and their 
(immutable) metadata in RADOS omap K/V. We want to be able to access the 
objects without Dovecot. This is not possible if RADOS is hidden behind a 
fs-rados module. The format of the stored objects would be different and 
depended on the storage module sitting in front of fs-rados.
Another reason is that at the fs level the operations are to decomposed. We 
would not have any, as with the dictionaries, transactional contexts etc. This 
context information allows us to use the RADOS operations in an optimized way. 
The storage API is IMO the right level of abstraction. Especially if we follow 
our long term goal to eliminate the fs needs for index data to. I like the 
internal abstraction of sdbox/mdbox a lot. But for our purpose it should have 
been on mail and not file level.

But building a fs-rados should not be very hard.

BTW. We've also been planning on open sourcing some of the obox pieces, mainly 
fs-drivers (e.g. fs-s3). The obox format maybe too, but without the "metacache" 
piece. The current obox code is a bit too much married into the metacache 
though to make open sourcing it easy. (The metacache is about storing the 
Dovecot index files in object storage and efficiently caching them on local 
filesystem, which isn't planned to be open sourced in near future. That's 
pretty much the only difficult piece of the obox plugin, with Cassandra 
integration coming as a good second. I wish there had been a better/easier 
geo-distributed key-value database to use - tombstones are annoyingly 
troublesome.)


That would be great.

And using rmb-mailbox format, my main worries would be:
* doesn't store index files (= message flags) - not necessarily a problem, as 
long as you don't want geo-replication

Your index management is awesome, highly optimized and not easily 
reimplemented. Very nice work. Unfortunately it is not using the fs-api and 
therefore not capable of being located on not fs storage. We are believing that 
CephFS will be a good and stable solution for the next time. Of course it would 
be nicer to have a lib-index that allows us to plug in different backends.

* index corruption means rebuilding them, which means rescanning list of mail 
files, which means rescanning the whole RADOS namespace, which practically 
means rescanning the RADOS pool. That most likely is a very very slow 
operation, which you want to avoid unless it's absolutely necessary. Need to be 
very careful to avoid that happening, and in general to avoid losing mails in 
case of crashes or other bugs.

Yes, disaster is a problem. We are trying to build as many rescue tools as 
possible but in the end scanning mails is involved. All mails are stored within 
separate RADOS namespaces each representing a different user. This will help us 
to avoid scanning the whole pool. But it this not should not be a regular 
operation. You are right.

* I think copying/moving mails physically copies the full data on disk

We tried to optimize this. Moves within a users mailboxes are done without 
copying the mails by just changing the index data. Copies, when really 
necessary, are done be native RADOS commands (OSD to OSD) without transferring 
the data to the client and back. There is potential