Re: an e-mail client for dovecot ?

[Miquel van Smoorenburg]

On 18/07/16 11:46, Stephan Bosch wrote:
>
>
> Op 16-7-2016 om 18:12 schreef Charles Marcus:
>>
>> On July 16, 2016 4:02:33 AM EDT, Spyros Tsiolis 
>> wrote:
>>> Since I have quite some experiece with thunderbird, I know most of
>>> its shortcomings
>> Care to elaborate? Thunderbird is far from perfect, but is by far the
>> best IMAP client available.
>>
>> Most times you can work around supposed short comings (if what you
>> think are short comings actually are, often they are not)...
>
> I agree. I haven't seen anything better so far. Still, with my 100+
> folders it regularly hangs for a few seconds while it is presumably
> doing stuff in the background. So, for example composing a message is
> often a frustrating activity. This is enough reason for me to look for
> an alternative client, but there is no real alternative...

Known problem. Sort of a indexing thundering herd problem.

Preferences -> Advanced -> Config Editor, set  mail.db.idlelimit to a
large number. I set it to 3000. Fixed it for me..

Mike.

Re: v2.2.22 release candidate released

[Miquel van Smoorenburg]

On 04/03/16 14:33, Timo Sirainen wrote:

There are some larger changes here, especially to doveadm to make it
support HTTP API. There's still time to do smaller tweaks to the API,
so let us know if you have some improvement ideas. Note that the API
was designed to look mostly like JMAP, which we're planning to
implement also for v2.3. The plan is to fork v2.3 development tree
soon.


Let me say that I think it's really cool that you're adding support for 
JMAP. This will make it possible for front-end developers to build 
webmail or mail-aware applications right on top of dovecot, instead of 
first having to build a server-side middleware layer between IMAP and 
the application.


Question: some time ago you mentioned that you were going to work on 
caldav/carddav support. What is the status of that, and will the 
calendar/contacts database be available over JMAP as well?


Thanks,

Mike.

Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve

[Miquel van Smoorenburg]

On 8-01-14 5:46 PM, Charles Marcus wrote:

On 2014-01-07 9:20 PM, Greg Rivers gcr+dove...@tharned.org wrote:

So for the archives, to get sieve's envelope :detail ... working
with sendmail and dovecot LMTP, do the following:

1) Add lda_original_recipient_header = X-Original-To to 15-lda.conf

2) Add the following rule to sendmail.mc to add a X-Original-To:
header to every message:

LOCAL_CONFIG
H?${u}?X-Original-To: $u


This probably only works if there is exactly one RCPT TO in the LMTP 
session. If there are multiple recipients, sendmail cannot add that 
header. What should it contain?


So you have to limit sendmail to max. one recipient per LMTP session. 
Hopefully you don't use SIS.


Mike.

Re: [Dovecot] Encryption solution for messages at rest

[Miquel van Smoorenburg]

On 28/10/13 23:22, Frerich Raabe wrote:

On 2013-10-28 20:23, Reindl Harald wrote:

Am 28.10.2013 20:14, schrieb Douglas Mortensen:

However, it would be nice to know that even if we were breached, the
emails on the server were encrypted and would be completely useless
to an attacker.
This type of encryption is ideal and some regulations prefer
(although don't require) it


impossible and useless
if someone comes that far he can also read whatever configuration
containing the keys


In principle, this can be addressed by employing asymmetric key encryption.

You could imagine a system which requires users to generate a key pair
and then submit their public key. The mail system will encrypt all mail
received for a user with that users public key. When accessing the mail,
the user configures his user agent to use the private key to decrypt the
mail.

In practice, it's probably not that easy:

1. I suppose you'd have to be careful to not break features like
server-side searching though. If you only store encrypted mail, the only
moment where the system sees the plain mail is when it's received. So
you'd probably need to index it at that point and then use that index
for subsequent queries. Once the mail is written to disk, the server
never sees the real data anymore.

2. Different mail storage formats probably work differently well. mbox
is right out, with Maildir it might not be acceptable to encode the raw
mail file - I don't know whether Dovecot uses any actual contents of
files with Maildir (as opposed to the Dovecot-specific indices and the
file name). If it does, then you should maybe just encrypt just the body
but no headers or similiar.

There's surely more to consider, but I think this is anything but
impossible and useless. Accessing sensitive data which is stored on an
untrusted system is an old and solved problem, I wouldn't be surprised
if you just have to consider implementation details in the case of a
mail server.


Well you can generate the public and private key on the server, then set 
the users password as the keyphrase, and leave it stored on the server.


Incoming mail would be automatically encrypted with the public key, then 
stored.


When the user logs in to imap/pop the password is not only used for 
authentication, but also to unlock the private key. Dovecot can then 
decrypt the messages on the fly.


Basically this is how Lavamail worked. It is reasonably secure, but 
doesn't help against a hostile root user on the server that hacks 
dovecot to just log the password when a user logs in. Or someone who has 
acquired your SSL keys and taps your internet connection.


Mike.

Re: [Dovecot] crashes on 2.0.16

[Miquel van Smoorenburg]

On 19-12-11 4:13 AM, Noel Butler wrote:

On Mon, 2011-12-19 at 02:32 +0100, Sven Hartge wrote:


Noel Butlernoel.but...@ausics.net  wrote:

On Mon, 2011-12-19 at 00:32 +0100, Cor Bosman wrote:



# 2.0.16: /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 2.6.32.36-xsserver x86_64 Debian 6.0.3



Have you tried using a modern kernel? that one is about 2 years old.


Well, this _is_ the kernel from Debian Stable and based on the
Long-Term-Release from the kernel maintainers.



So what? It is not anything current, that the kernel dev team would
waste their time on.


The kernel developers actually do waste their time on the 2.6.32.x 
kernel. It's a long-term stable kernel, there are frequent releases on 
kernel.org (I admit, .36 is a bit long in the tooth, latest is .50, 
released about 2 weeks ago).


Mike.

Re: [Dovecot] POP3 vs. IMAP Load/Memory usage in Dovecot 1.0.15

[Miquel van Smoorenburg]

On 11-07-11 5:03 PM, Stan Hoeppner wrote:

Given that you're running Dovecot 1.0.15 I'm guessing you're using
CentOS or RHEL 5.x and thus have kernel 2.6.18-xxx.  2.6.18 is 5 years
old now and not inappropriate for a modern 2 socket, 6 core
HyperThreading box.  You need a much newer kernel, preferably in the
2.6.3x series.  2.6.18 could be reporting incorrect load numbers on
these machines.


RHEL kernel version numbers do not say much. The redhat 2.6.18 is 2.6.18 
+ a boatload of enterprise load patches and backports from 2.6.2x. 
OTOH, dovecot 1.0.15 is ancient indeed :)



The discrepancies lie in two areas:

1) Load Average


On Linux, load average strictly shows total system CPU usage in
intervals, nothing else.


That would be FreeBSD, AFAIK. On linux, I/O does add to the load 
average. A process in state 'D' (Disk wait, could be NFS wait too btw) 
adds '1' to the load. If you have a broken NFS server and 2000 processes 
waiting on I/O, the reported load will go over 2000.


You get a better impression of system load by running 'top' and paying 
attention to the number on the 'cpu' line: us == time spent in user 
process, sy = kernel, id = idle, wa = I/O wait, si = interrupts


Press '1' while in top to expand the view to all CPUs seperately. Quite 
enlightening.



Given that all mail apps are 100% IO bound, never CPU or memory bound,
I'd guess you'll never see a load average over 4.00 on any of these
machines with less than 1000 concurrent connections.


Well, see above. Also, if you have SSL enabled, the crypto will actually 
eat quite a bit of CPU if you have a lot of network traffic.


Mike.

Re: [Dovecot] Proxying to a DNS Name

[Miquel van Smoorenburg]

On di, 2010-01-26 at 10:32 +0100, Jakob Hirsch wrote:
 Timo Sirainen, 2010-01-25 20:29:
 
  b) Get some async DNS library from somewhere.
  I have been looking for that as well recenly, and I stumbled upon the
  unbound library, part of the unbound project.
  I know there are a few of them, but I'd prefer to use the system's own
  resolver. A few reasons that I can think of:
 
 adns seems to be pretty mature and should be available on most systems
 as a maintained package 

Adns has no IPv6 support.

Mike.

Re: [Dovecot] Proxying to a DNS Name

[Miquel van Smoorenburg]

On Mon, 2010-01-25 at 20:53 +0200, Timo Sirainen wrote:
 
 b) Get some async DNS library from somewhere.

I have been looking for that as well recenly, and I stumbled upon the
unbound library, part of the unbound project.

http://unbound.net/documentation/libunbound.html

HTH,

Mike.

Re: [Dovecot] Degeneration of CPU Performance

[Miquel van Smoorenburg]

On Thu, 2009-05-07 at 15:40 -0300, Thiago Monaco Papageorgiou wrote:
 Hello everybody!
 
 We have a interesting issue about dovecot behavior here. First, the 
 scenario:
 We have 2 server running with the same load, one with our old pop3 
 solution (out of date) and other with Dovecot. We realized that dovecot 
 are comsuming more CPU, and this consumption is growing day by day. When 
 we starts dovecot, it runs between 40%-45% of CPU consumption and our 
 old solution runs on 30-35%. This is quite acceptable, so no problem 
 here. The problem is one day after it jumps to 45%-55% of cpu 
 comsunption while the old pop3 solution runs on the same CPU consumption 
 of one day before (30%-35). I attached a graph with this information.

I see you're using NFS and Linux. We've seen something similar.

Try to find out where this CPU time is being spent - in the kernel, or
in userland. 'top' will tell you, just start it, and look at the second
or 3rd line where it says 'CPU'. 'us' is user time, 'sy' is system time,
and 'si' is 'system interrupt'. The latter two are time spent in the
kernel.

If all CPU is used by 'us' then it's really dovecot that is eating
cycles. If it is 'sy' or 'si' it's the kernel.

In that case, you might want to upgrade. Upgrade to 2.6.27.10 at least,
2.7.27.latest preferably - many NFS bugs have been fixed there. I have
no idea if there is a drop-in CentOS kernel = 2.6.27.10 - you might
have to compile your own kernel.

Mike.

Re: [Dovecot] How to get rid of locks

[Miquel van Smoorenburg]

On Sat, 2007-04-07 at 22:30 +0300, Timo Sirainen wrote:
 Although Dovecot is already read-lockless and it uses only short- 
 lived write locks, it's be really nice to just get rid of the locking  
 completely. :)
 
 I just figured out that O_APPEND is pretty great. If the operating  
 system updates seek position after writing to a file opened with  
 O_APPEND, writes to Dovecot's transaction log file can be made  
 lockless.

Doest his mean there's even less chance of indexes working on NFS (where
O_APPEND doesn't really work) ?

That's a pity, as a lot of larger sites use NFS. They are already forced
to use indexes on local disk - and dovecot seems to rely on indexes more
and more (fulltext index, shared mailboxes, etc).

And mailbox formats like dbox don't even work without an index.

I had hoped that the existing index code would be made more reliable and
network-filesystem safe first.

Mike.