Re: [mail-crypt-plugin] How to decrypt mailbox?

[Aki Tuomi via dovecot]

On 21.5.2019 8.03, emordin via dovecot wrote:
> Hi,
>
> So I am able to encrypt email using the crypt plugin, but when I try
> to access the email by logging in thru mutt or roundcube the email is
> still encrypted.
> Is the decryption process automatic or do I have to create a custom
> program with the decrypt.rb code?
>
> Thanks.
>
>
> Sent with ProtonMail  Secure Email.
>
Hi!

You need to enable mail_crypt plugin globally, not just for LDA.

Aki

Re: Dovecot with LDAP Proxy

[Aki Tuomi via dovecot]

On 20.5.2019 20.06, Federico Bartolucci via dovecot wrote:
> Hello,
>
> configuring Dovecot with LDAP authentication, adding the parameter in
> ther sql config file:
>
> pass_attrs = \
>     =proxy=y
>
> I see then backend connections always addressed to localhot port 143:
>
> /user=uten...@domanin.com proxy   lip=127.0.0.1   lport=143   /
>
> while I expect that connections would be managed by the director and
> then addressed to my backend IPs and specific port.
> Is there a way to configure ldap proxy to get that behavior?
>
> Thanks in advance.
>
> -federico

Hi!

Have you read https://wiki2.dovecot.org/Director ?

Aki



signature.asc
Description: OpenPGP digital signature

[mail-crypt-plugin] How to decrypt mailbox?

[emordin via dovecot]

Hi,

So I am able to encrypt email using the crypt plugin, but when I try to access 
the email by logging in thru mutt or roundcube the email is still encrypted.
Is the decryption process automatic or do I have to create a custom program 
with the decrypt.rb code?

Thanks.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: Further issues on FTS engine

[John Fawcett via dovecot]

On 20/05/2019 08:27, Joan Moreau via dovecot wrote:
>
> Hi,
>
> Additionally to the long list of problem on the FTS previously
> discussed, here a new:
>
>
> WHen I reset the indexes, the indexer-worker seems paralelleizing the
> indexing (which is good), however, the number available in "ps aux |
> grep dove" shows that it does not move:
>
> dovecot 28549 0.0 0.0 8620 3920 ? S 06:20 0:00 dovecot/indexer [0
> clients, 3 requests]
> mailuse+ 28550 98.6 0.1 167412 86916 ? R 06:20 5:28
> dovecot/indexer-worker [j...@grosjo.net  - 800/37755]
>
>
> Looking further, if I put a tracer in teh backend, it treats the
> *same* message several times in parallel, and therefore does not move
> very fast on the global indexing of the box
>
> ANy clue ?
>
> THanks
>
>
Hi Joan

which version of dovecot are you using? I tried running ps aux | grep
dove on latest version but I don't see this behaviour.

Can you post some evidence of the same message being indexed serveral
times in parallel?

John

enforcing multiple per-mailbox quotas for shared mailboxes

[Jost-Philip Matysik via dovecot]

Hi!

I'm trying to get quotas for shared mailboxes set up on my server. It's
not working, and I fail to understand why. Documentation for setup of
this complexity is rather scarce on the web, and the discussions I found
either don't directly apply or terminate with "I got it working" but
no explanation.
Can someone please help?
The setup is rather lengthy and complicated, so I'll try to give a
summary first for easier understanding.
All help is appreciated! Please respond if you need more info!

Thanks!
Best regards,
Jost


Basic setup (where am I coming from?):
==
- This is a Debian 9 system with a more recent version of dovecot
  installed from https://repo.dovecot.org/ce-2.3-latest/debian/stretch
- users have individual mailboxes with individual quotas  -- this works great!
- users can share mailboxes with other users through ACLs. To achieve
  this, there exists a wildcarded namespace with
  prefix="ZZZ_Freigaben/%%u" --this also works great!
==> up to here it's pretty much following the examples from the Wiki to
the letter.


Configuration goal (what do I want to achieve?):

- attach quotas to mailboxes, not logins
- when copying/moving mails across shared mailboxes during imap
  sessions, enforce quota based on target mailbox, not logged-in user
  doing the copying.
To clarify:
==> so if Bob has a quota of 500MB, all messages in Bob's mailbox
should count against (and only against!) Bob's quota, regardless of who
put them there.
==> if Alice has access to her own mailbox (directly), as well as Bob's
mailbox and Dave's mailbox (through sharing), she should see 3
individual quotas when logging in: her own quota (200MB) for everything
in her mailbox, bob's quota (300MB) for everything in Bob's mailbox, and
Dave's quota (10GB) for everything in Dave's mailbox. These 3 quotas
should be completely independant and neither block, nor override each
other.


Setup Idea (how I tried to get there):
==
- "quota=..." "quota_rule" and "quota_rule2" always refer to the user's
  own mailbox (with an additional rule for Trash). Everyone has those,
  so these are loaded statically from dovecot config file.
- "quota_rule" is overwritten from userdb with the user's individual
  mailbox quota (the more I like you, the more space you get...)
- since the number of different additional quotas required per user
  depends on how many mailboxes are shared with that user, individual
  "quota2=...", "quota3=...", "quotaN=..." fields are dynamically
  generated by the MySQL backend and loaded from userdb upon login.
- consequently, for each "quotaN=..." entry, a corresponding
  "quotaN_rule=*:storage=XXX" is generated and returned from userdb
  (substitute N=1,2,3,4,... accordingly)


Observations:
=
1. enforcing quota for the user's personal mailbox works as expected,
   both through IMAP and when delivering incoming mail
2. overriding "quota_rule=..." from userdb for the user's personal
   mailbox works great. Individual quota is recognized and enforced both
   through IMAP and when delivering incoming mail.
3. dynamically loading "quota2=...", "quota3=..." etc. from userdb
   doesn't seem to work at all! I can see them being added as extra
   fields in the logs upon user login, but the quota-plugin seems to
   completely ignore them. They are not enforces, and tools like
   'doveadm quota' list the userdb fields in the debug messages, but do
   not interpret them in any way. They do not throw errors either, the
   additional quota roots are just silently ignored.
4. the end result is that in an IMAP session the logged-in user's quota
   is enforced for their individual mailbox, but as soon as they write
   to someone else's mailbox (move a mail
   to /ZZZFreigaben/bob/Some-Subfolder), no quota is enforced at all!

Additional debugging done:
==
if I hardcode a "quota2=" and/or "quota3=" in the config file, I can
observe the following:
- If I hardcode "quota2=count:some_name:ns=ZZZ_Freigaben/", dovecot and
  doveadm will recognize the additional quota root. But since the folder
  "ZZZ_Freigaben/" on its own isn't a mailbox (it's just a path
  CONTAINING mailboxes), the quota is neither displayed in clients, nor
  enforced. It has no real-word effect, other than 'doveadm quota'
  showing an additional line.
- If I hardcode "quota2=count:other_name:ns=ZZZ_Freigaben/postmaster/"
  in the config file (with that path being the real IMAP path to a
  shared mailbox), dovecot will complain in the log saying

Error: quota: Unknown namespace: ZZZ_Freigaben/postmaster/

dovecot will start and work for the most part, but again completely
ignore settings for the additional quota.

- additionally, trying to override "quota2_rule=..." from userdb doesn't
  work as it does with "quota_rule=..."! If I have both
  "quota_rule=..." and "quota2_rule=..." in the config file as well as
  returned 

Re: Create a malicious directory

[@lbutlr via dovecot]

On 20 May 2019, at 06:50, Reto via dovecot  wrote:
> How is that dangerous?

Exactly.

-- 
At night when the bars close down
Brandy walks through a silent town
And loves a man who's not around

Re: Create a malicious directory

[L A Walsh via dovecot]

First, you might want to control access to who is allowed to use
your server, your email and dovecot.  If they are malicious, maybe you
want to disallow their access.

Second, you might want to make sure that dovecot and doveadm,
do not have permissions to run programs outside of a few that
are needed.  Perhaps put them in a chroot jail?

Or install a stronger kernel security module.  Some disallow things
by roles, some disallow things by labels and some by path. 
You can also set a file to be
append only, so delete won't work on it (see chattr(1)).

There are quite a few ways to add more security, but such issues
are complex and well beyond the scope of this list.  If you
are concerned with security, and don't know how to configure it,
consider disallowing all access to your server, except for yourself.

*cheers*







On 2019/05/19 21:22, lty via dovecot wrote:
>
> Use scripts to create some malicious directories. Here is my creation
> process. How can I prevent the creation of these directories?
> I used the python imapclient script to create a directory.
>
> There may be no big threat to dovecot, but it is dangerous for doveadm.
>
On 2019/05/19 18:22, hfh via dovecot wrote:

Directory name have some malicious characters, is it safe?How can I
exclude some characters,thanks!大笑



Realistically, nothing is 100% safe unless it is stored in 100ft of
concrete and buried where no one can find it.  Safety and usability are
ever at odds
with one another.

Dovecot with LDAP Proxy

[Federico Bartolucci via dovecot]

Hello,

configuring Dovecot with LDAP authentication, adding the parameter in
ther sql config file:

pass_attrs = \
    =proxy=y

I see then backend connections always addressed to localhot port 143:

/user=uten...@domanin.com proxy   lip=127.0.0.1   lport=143   /

while I expect that connections would be managed by the director and
then addressed to my backend IPs and specific port.
Is there a way to configure ldap proxy to get that behavior?

Thanks in advance.

-federico


signature.asc
Description: OpenPGP digital signature

Re: Create a malicious directory

[Reto via dovecot]

How is that dangerous?
If you pipe output from a directory listing to *any* command you need to 
sanitize it.

That's normal if you have data that can be created by a user. The issue is 
known since the very beginning of Linux

Re: Dict issue with PostgreSQL for last_login plugin (duplicate key)

[mabi via dovecot]

‐‐‐ Original Message ‐‐‐
On Sunday, May 19, 2019 10:45 PM, John Fawcett via dovecot 
 wrote:

> so basically if this works just as well:
>
> INSERT INTO last_logins (last_login,username,domain) VALUES 
> (1558273000,'u...@domain.tld','domain.tld') ON CONFLICT DO UPDATE SET 
> last_login=1558273000,domain='domain.tld';
>
> then the fix can be altered to attached file which is more similar to the 
> MYSQL syntax and does not require extra logic to get the username field.

Unfortunately this query does not work, it looks like it really requires the 
column name as you can see below from the error message:

ERROR:  ON CONFLICT DO UPDATE requires inference specification or constraint 
name
LINE 1: ...ain) VALUES (1558273000,'u...@domain.tld','domain.tld') ON CONFLIC...
 ^
HINT:  For example, ON CONFLICT (column_name).

But if you can use the table's primary key as default for the column name as 
you mention in your other mail then that should work. I am using here 
PostgreSQL 10.5 by the way.

I still haven't figured out yet how to recompile properly Dovecot on OpenBSD 
with your patch but I will give it another shot tonight.

Further issues on FTS engine

[Joan Moreau via dovecot]

Hi, 


Additionally to the long list of problem on the FTS previously
discussed, here a new: 


WHen I reset the indexes, the indexer-worker seems paralelleizing the
indexing (which is good), however, the number available in "ps aux |
grep dove" shows that it does not move: 


dovecot 28549 0.0 0.0 8620 3920 ? S 06:20 0:00 dovecot/indexer [0
clients, 3 requests]
mailuse+ 28550 98.6 0.1 167412 86916 ? R 06:20 5:28
dovecot/indexer-worker [j...@grosjo.net  - 800/37755] 


Looking further, if I put a tracer in teh backend, it treats the *same*
message several times in parallel, and therefore does not move very fast
on the global indexing of the box 

ANy clue ? 


THanks