2.3.10 + lazy expunge

[Matt Bryant]

Hi,

so currently run dovecot 2.2.x on CentOS 7 box and was looking to 
upgrade to 2.3.10. I use lazy expunge atm into a different namespace but 
saw on the new doco pages that is is depracted in 2.3.0.


Have tested and still seems to work so question is more around why ? Why 
would this be deprecated given using a different namespace allows 2 things


a) the folder where message is located is taken accross so if I want to 
restore and know where it went


b) namespace allows me to specify an alternate location for storing the 
messages.


Also given it does still work is there any indication as to what version 
the deprecation basically equates to it not working.


rgds

Matt

-- 8< -


   namespace

Deprecated since version v2.3.0.

Re: Simple backup of maildir folder

[Joseph Tam]

On Sun, 31 May 2020, Laura Smith wrote:


A couple of notes on this quite useful script:

My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:


In my scripts I tend to create a tempdir and then tempfiles within that.  It 
makes the cleanup routine neater, e.g. at the top of my scripts :

TEMP_DIR=$(mktemp -qd || { doLog "Failed to make temp dir !"; exit 1; })
rmTmpFiles() { rm -rf "${TEMP_DIR}"; }
createTempFile() { local MYTEMP=$(mktemp -qp "${TEMP_DIR}" || doLog "Failed to 
create temp file"; exit 1); echo $MYTEMP; }

Also my backup scripts have locking procedures built-in so as to avoid race 
conditions.


You might also want a trap handler that does a cleanup in case something
goes sideways in the middle of processing e.g.

trap rmTmpFiles 0

Joseph Tam 

Re: Running doveadm without config file?

[Joseph Tam]

Sami Ketola  writes:


I tried this with /dev/null and /tmp/empty.conf but ran into another wall

doveadm(root): Fatal: execv(/usr/bin/doveconf) failed: No such file or 
directory


How did you install dovecot on that system since /usr/bin/doveconf is part of 
the base package?


Manual install: not using a package manager.  (I've edited the doveconf
location, but you've outed me.)  I was hoping to get "doveadm pw"
working on non-dovecot servers without having to provide seemingly
irrelevant dependencies, but it's probably more bother than its worth.
Thanks, anyways.

Joseph Tam 

Re: identify 143 vs 993 clients

[Joseph Tam]

On Sun, 31 May 2020, Jean-Daniel wrote:


So yes the safest way to go is to just use port 993, but as long as
the client is not set to a "TLS if available" option then port 143 is
also safe.


I don?t think you can call an option safe if it relies on the users to
properly configure their client.  We all know that users are usually
bad at following instructions ;-)


I think Peter nailed it, but let's put it this way: the server policy
is irrelevant to client side policy.  *If* the client has been not been
configured to disable plaintext password, a malicious party can coax
a password out of a client, despite what the server policy is, or even
whether the server is available.

Only allowing implicit SSL will guarantee insecurely configured clients
will fail (and maybe not even that if it autoconfigures), but it doesn't
prevent them from being exploited.

Joseph Tam 

Re: Simple backup of maildir folder

[Francis Augusto Medeiros-Logeay]

> On 31 May 2020, at 11:13, Laura Smith  
> wrote:
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
>> On Sunday, 31 May 2020 09:35, @lbutlr  wrote:
>> 
>> 
>> 
>> A couple of notes on this quite useful script:
>> 
>> My mktemp does not support -p (FreeBSD 12.1) is I had to change the script 
>> to:
>> 
> 
> 
> In my scripts I tend to create a tempdir and then tempfiles within that.  It 
> makes the cleanup routine neater, e.g. at the top of my scripts :
> 
> TEMP_DIR=$(mktemp -qd || { doLog "Failed to make temp dir !"; exit 1; })
> rmTmpFiles() { rm -rf "${TEMP_DIR}"; }
> createTempFile() { local MYTEMP=$(mktemp -qp "${TEMP_DIR}" || doLog "Failed 
> to create temp file"; exit 1); echo $MYTEMP; }
> 

I don’t think I need to clean up, and my “temp_dir” will end up being 
permanent, as to make doveadm backup snappier I will simply maintain the 
directory there and use crown jobs to update the dir. 


> Also my backup scripts have locking procedures built-in so as to avoid race 
> conditions.

Also not sure if that’s needed when using doveadm backup, as it takes care of 
the potential race conditions. 

So the idea is to use doveadm to a local folder, then rsync it to a remote 
server where snapshots can be easily created. 

It annoys me have to do the doveadm to the local server - seems like a waste of 
disk space, but since maildirlock is not working and since doveadm backup to a 
remote server requires a bit more work to, well, to work, so I guess this is a 
simple and quick solution. 

Best,

Francis 

Re: I can no longer use TLS for Windows7 and Outlook

[Benny Pedersen]

On 2020-05-31 11:11, Kostya Vasilyev wrote:


In terms of Dovecot ciphers config, Windows should be happy with
TLS_RSA_WITH_3DES_EDE_CBC_SHA which is less broken than the other
older ciphers.


lets hope that dovecot allow tls1 and still can disable tls1.1, tls 1.1 
is weaker then tls 1.0


better solution is to drop windows 7, and old unsupported mac

auth_policy_server vs client_id and x-originating-ip

[Zdeněk Zámečník]

I run into troubles when trying to set up auth_policy_server in Dovecot 
2.3.10.1. It works almost as expected but I cannot get client ID in this 
process.


By setting up "imap_id_log=*" I see in log that Dovecot gets details 
about mail client like name and version:


May 31 14:20:58 mail dovecot: 
imap(x...@example.xxx)<24796>: ID sent: 
name=Thunderbird, version=68.8.1



But the auth_policy_server is getting all details except this ID, it's 
empty:


May 31 14:20:58 mail auth-policy[10357]: {
May 31 14:20:58 mail auth-policy[10357]:   device_id: '',
May 31 14:20:58 mail auth-policy[10357]:   login: 'x...@example.xxx',
May 31 14:20:58 mail auth-policy[10357]:   protocol: 'imap',
May 31 14:20:58 mail auth-policy[10357]:   pwhash: '097a',
May 31 14:20:58 mail auth-policy[10357]:   remote: '1.2.3.4',
May 31 14:20:58 mail auth-policy[10357]:   tls: true
May 31 14:20:58 mail auth-policy[10357]: }


However in some cases I see that client_id is passed to auth_policy_server:

May 31 14:27:41 mail auth-policy[10357]: {
May 31 14:27:41 mail auth-policy[10357]:   device_id: '"name" 
"Outlook-iOS-Android" "version" "2.0"',

May 31 14:27:41 mail auth-policy[10357]:   login: 'y...@example.xxx',
May 31 14:27:41 mail auth-policy[10357]:   protocol: 'imap',
May 31 14:27:41 mail auth-policy[10357]:   pwhash: '0b63',
May 31 14:27:41 mail auth-policy[10357]:   remote: '3.4.5.6',
May 31 14:27:41 mail auth-policy[10357]:   tls: true
May 31 14:27:41 mail auth-policy[10357]: }

I think I am missing some important point. Maybe IMAP command ID and 
client_id are totally different. Can you please advise? Is it possible 
to pass details about mail client to auth_policy_server? Second question 
is: how I can get "x-originating-ip" from ID command to auth_policy_server?


Below is my config file:

# 2.3.10.1 (a3d0e1171): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.10 (67bf5bd7)
# OS: Linux 5.3.18-2-pve x86_64 Debian 10.4
# Hostname: mail.z-technics.com
auth_cache_size = 2 M
auth_cache_ttl = 5 mins
auth_master_user_separator = *
auth_mechanisms = plain login
auth_policy_check_before_auth = no
auth_policy_hash_nonce = # hidden, use -P to show it
auth_policy_report_after_auth = no
auth_policy_server_timeout_msecs = 1500
auth_policy_server_url = http://127.0.0.1:8090/
dict {
  acl = pgsql:/etc/dovecot/dovecot-dict-sql.conf.ext
  quota = pgsql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
disable_plaintext_auth = no
imap_client_workarounds = delay-newmail
imap_hibernate_timeout = 5 secs
imap_id_log = *
imap_id_retain = yes
login_trusted_networks = 127.0.0.1
mail_gid = 2000
mail_home = /var/vmail/%d/%n
mail_location = mdbox:~/mdbox:ALT=/var/vmail-archive/%d/%n/mdbox
mail_max_userip_connections = 60
mail_plugins = acl zlib fts quota
mail_uid = 2000
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope 
encoded-character vacation subaddress comparator-i;ascii-numeric 
relational regex imap4flags copy include variables body enotify 
environment mailbox date index ihave duplicate mime foreverypart 
extracttext vacation-seconds editheader imapsieve vnd.dovecot.imapsieve

mdbox_rotate_interval = 1 days
mdbox_rotate_size = 16 M

passdb {
  args = /etc/dovecot/dovecot-ldap.conf
  driver = ldap
}
passdb {
  args = /etc/dovecot/masters.db
  driver = passwd-file
  master = yes
  pass = yes
}
plugin {
  acl = vfile
  acl_shared_dict = proxy::acl
  imapsieve_mailbox1_before = file:/var/vmail/sieve/report-spam.sieve
  imapsieve_mailbox1_causes = COPY
  imapsieve_mailbox1_name = Spam
  imapsieve_mailbox2_before = file:/var/vmail/sieve/report-ham.sieve
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_from = Spam
  imapsieve_mailbox2_name = *
  imapsieve_mailbox3_before = file:/var/vmail/sieve/report-spam.sieve
  imapsieve_mailbox3_causes = COPY
  imapsieve_mailbox3_name = Junk
  imapsieve_mailbox4_before = file:/var/vmail/sieve/report-ham.sieve
  imapsieve_mailbox4_causes = COPY
  imapsieve_mailbox4_from = Junk
  imapsieve_mailbox4_name = *
  mailbox_alias_new = Sent Messages
  mailbox_alias_new2 = Sent Items
  mailbox_alias_new3 = Deleted Items
  mailbox_alias_old = Sent
  mailbox_alias_old2 = Sent
  mailbox_alias_old3 = Trash
  quota = dict:User quota::proxy::quota
  quota_grace = 10%%
  quota_rule2 = Trash:ignore
  quota_rule3 = Junk:ignore
  quota_warning = storage=80%% quota-warning 90 %u
  quota_warning2 = storage=85%% quota-warning 95 %u
  quota_warning3 = storage=95%% quota-warning 105 %u
  sieve = /var/vmail/%d/%n/sieve/.sieve
  sieve_after = /var/vmail/%d/%n/sieve/autoreply.sieve
  sieve_before = /var/vmail/sieve/global.sieve
  sieve_dir = /var/vmail/%d/%n/sieve
  sieve_extensions = +editheader +vacation-seconds
  sieve_global_dir = /var/vmail/sieve/
  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
  sieve_max_redirects = 20
  sieve_pipe_bin_dir = /usr/lib/dovecot
  sieve_plugins = sieve_imapsieve sieve_extprograms
  sieve_vacation_send_from_recipient = yes
}
protocols = 

Re: Simple backup of maildir folder

[Laura Smith]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, 31 May 2020 09:35, @lbutlr  wrote:


>
> A couple of notes on this quite useful script:
>
> My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:
>


In my scripts I tend to create a tempdir and then tempfiles within that.  It 
makes the cleanup routine neater, e.g. at the top of my scripts :

TEMP_DIR=$(mktemp -qd || { doLog "Failed to make temp dir !"; exit 1; })
rmTmpFiles() { rm -rf "${TEMP_DIR}"; }
createTempFile() { local MYTEMP=$(mktemp -qp "${TEMP_DIR}" || doLog "Failed to 
create temp file"; exit 1); echo $MYTEMP; }

Also my backup scripts have locking procedures built-in so as to avoid race 
conditions.

Re: I can no longer use TLS for Windows7 and Outlook

[Kostya Vasilyev]

On 5/31/20 11:54 AM, Aki Tuomi wrote:


On 31/05/2020 07:36 Mark Constable > wrote:



I currently use Ubuntu 20.04 with Dovecot 2.3.7.2 and OpenSSL 1.1.1f.

A few months ago there was an update to all these systems and since
then I've had to talk W7 and old Mac clients through disabling ports
993/995 with TLS enabled back to ports 143/110 without SSL or they
could not pick up email. Thunderbird users (ie; me) were unaffected.

Could anyone share a set of port 993/995 SSL settings known to work
with Windows7 and Outlook16 using "dovecot -n|grep ^ssl_" please ?

Mine is currently...

ssl_ca = 

ssl_min_protocol = TLSv1.0
ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL

if this works try tuning cipherlists to more secure value.

---
Aki Tuomi



Since you mention the newest Ubuntu version, it may (most likely) be 
necessary to enable TLS 1.0 / 1.1 in openssl as well. I ran into this 
with Debian 10 some time ago.


/etc/ssl/openssl.conf

[system_default_sect]
-MinProtocol = TLSv1.2
+MinProtocol = TLSv1

In terms of Dovecot ciphers config, Windows should be happy with 
TLS_RSA_WITH_3DES_EDE_CBC_SHA which is less broken than the other older 
ciphers.


-- K

Re: I can no longer use TLS for Windows7 and Outlook

[Aki Tuomi]

 
 
  
   
  
  
   
On 31/05/2020 07:36 Mark Constable  wrote:
   
   

   
   

   
   
I currently use Ubuntu 20.04 with Dovecot 2.3.7.2 and OpenSSL 1.1.1f.
   
   

   
   
A few months ago there was an update to all these systems and since
   
   
then I've had to talk W7 and old Mac clients through disabling ports
   
   
993/995 with TLS enabled back to ports 143/110 without SSL or they
   
   
could not pick up email. Thunderbird users (ie; me) were unaffected.
   
   

   
   
Could anyone share a set of port 993/995 SSL settings known to work
   
   
with Windows7 and Outlook16 using "dovecot -n|grep ^ssl_" please ?
   
   

   
   
Mine is currently...
   
   

   
   
ssl_ca = 
   
ssl_cert = 
   
ssl_dh = # hidden, use -P to show it
   
   
ssl_key = # hidden, use -P to show it
   
   
ssl_options = no_compression no_ticket
   
   
ssl_prefer_server_ciphers = yes
   
   

   
   
I have commented out ssl_cipher_list, ssl_min_protocol and others to
   
   
get back to whatever the defaults are so I am not simply guessing what
   
   
the optimal settings would be to cover Win7 and up.
   
   

   
   
Yes I know Win7 is no longer supported but that does not help the 100s
   
   
of older users I have that can't/won't upgrade their computers.
   
  
  
   
  
  
   ssl_min_protocol = TLSv1.0
  
  
   ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL
  
  
   
  
  
   if this works try tuning cipherlists to more secure value.
  
  
   
  
  
   ---
  
  
   Aki Tuomi
  
 

Re: I can no longer use TLS for Windows7 and Outlook

[@lbutlr]

On 30 May 2020, at 22:36, Mark Constable  wrote:
> 993/995 with TLS enabled back to ports 143/110 without SSL or they
> could not pick up email. Thunderbird users (ie; me) were unaffected.

Insecure mail login is far too risky to allow. I don't even allow it within a 
LAN.

> Could anyone share a set of port 993/995 SSL settings known to work
> with Windows7 and Outlook16 using "dovecot -n|grep ^ssl_" please ?

If the users cannot upgrade to an OS that works with TLS 1.2, then you need to 
either move them to a client that does its own TLS handling, or setup webmail 
(like Horde or Raoundcube).

Those clients on older machines are similarly going to have trouble accessing 
banks, health sites, or other secure logins as TLS 1.0 and 1.1 are not 
supported anymore. In fact, if it were not for the current pandemic, their 
browsers would already have lost TLS 1.0 and 1.1 abilities.



-- 
Margo: Give me a phaser and a red shirt.
Male centurion: What?

Re: Simple backup of maildir folder

[@lbutlr]

On 29 May 2020, at 23:49, Admin Beckspaced  wrote:
> I also have maildir as mailbox format and use the following script to do 
> daily backups
> 
> https://github.com/tachtler/dovecot-backup

A couple of notes on this quite useful script:

My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:

DIR_TEMP=$($MKTEMP_COMMAND -d $TMP_FOLDER -t $SCRIPT_NAME)

Which gives a temp folder along the lines of

/tmp/dovecot_backup.IiZ00GyZ

I also changed the various date strings to date -Iseconds and date -R for the 
mail handling since the format in the script is not to spec, using

Fri, 29 May 2020 23:49:31 (-0600)

Instead of the

 -R, --rfc-email
  output date and time in RFC 5322 format. Example: Mon, 14   
  2006 02:34:56 -0600




-- 
FRIDAYS ARE NOT "PANTS OPTIONAL" Bart chalkboard Ep. AABF23

Re: I can no longer use TLS for Windows7 and Outlook

[Christian Kivalo]

On May 31, 2020 6:36:52 AM GMT+02:00, Mark Constable  wrote:
>I currently use Ubuntu 20.04 with Dovecot 2.3.7.2 and OpenSSL 1.1.1f.
>
>A few months ago there was an update to all these systems and since
>then I've had to talk W7 and old Mac clients through disabling ports
>993/995 with TLS enabled back to ports 143/110 without SSL or they
>could not pick up email. Thunderbird users (ie; me) were unaffected.
>
>Could anyone share a set of port 993/995 SSL settings known to work
>with Windows7 and Outlook16 using "dovecot -n|grep ^ssl_" please ?
The best would be to upgrade your clients to a more current OS that supports 
those ciphers or change the mail client to something that ships it's own 
SSL/TLS implementation like Thunderbird. 

I would under no circumstances allow access without TLS. 
You could also switch back to an older version of Ubuntu / openssl which in 
turn would allow the old clients to use SSL/TLS again. 
This would allow for an extended time period getting those clients to upgrade 
their OS. 
>Mine is currently...
>
>ssl_ca = ssl_cert = ssl_dh = # hidden, use -P to show it
>ssl_key = # hidden, use -P to show it
>ssl_options = no_compression no_ticket
>ssl_prefer_server_ciphers = yes
>
>I have commented out ssl_cipher_list, ssl_min_protocol and others to
>get back to whatever the defaults are so I am not simply guessing what
>the optimal settings would be to cover Win7 and up.
Nevertheless you're up to a good amount of work, for Win7 I found this [1] that 
links to MSDN [2] where it states:

TLS 1.1 & TLS 1.2 are enabled by default on post Windows 8.1 releases. Prior to 
that they were disabled by default. So the administrators have to enable the 
settings manually via the registry. Refer this article on how to enable this 
protocols via registry: https://support.Microsoft.com/en-us/kb/187498

I haven't tested this as I don't have a Win7 installation available. 

>Yes I know Win7 is no longer supported but that does not help the 100s
>of older users I have that can't/won't upgrade their computers.
There will probably be more problems relating to old OS and unsupported SSL/TLS 
versions in the future. 

Good luck. 

[1] https://support.globalsign.com/ssl/general-ssl/tls-protocol-compatibility
[2] 
https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/
-- 
Christian Kivalo

Re: Simple backup of maildir folder

[Admin Beckspaced]

My questions are:

- How much to I need to configure this new server? Do I need to 
setup user by user, or even install postfix (that's where my users 
are configured) to get it all backed up? I tried to install dovecot 
and running doveadm backup, but it complains the users are not there.
- What's the simplest way to configure dovecot without mirrowing my 
server so that this can work?


Best,

Francis

---
Francis Augusto Medeiros-Logeay
Oslo, Norway


Hello Francis,

I also have maildir as mailbox format and use the following script to
do daily backups

https://github.com/tachtler/dovecot-backup

There's also a more detailed how-to which explains how to do a restore.
But it's only in german language

https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:dovecot_backup_-_skript 



Google Translate is your friend ;)
perhaps this might help?

greetings
Becki



Thanks a lot Becki. I read your script, but the thing is that I want 
to backup to a remote server. Your script seems to be focused on a 
local backup. Did I get it right? But it still gives me a good idea of 
a possibility of backing up locally and rsyncing to another server.



Hello Francis,
I do exactly the same. Generate the backup of the mailboxes locally in a 
folder via the script.

And then rsync to another remote backup server.

works flawless ;)

Re: identify 143 vs 993 clients

[Peter]

On 31/05/20 6:50 pm, Jean-Daniel wrote:

Yes and no.  Some of the attack vectors mentioned are not reasonable and it really depends on the 
client.  Thunderbird, for example, used to have settings for plain text, TLS and "TLS if 
available", but the latter setting has not been available for some time which forces the user 
to choose either plain text or TLS at setup time now.  This means that the user would now have to 
change the setting in their client for a downgrade attack to work.  I can't speak for all MUAs but 
if they similarly have removed their "TLS if available" option or if the users explicitly 
don't pick that option (you can ask them not to in your setup instructions) then that type of 
downgrade attack cannot occur.

The other possible downgrade attack which was not mentioned but is equally 
mitigated by the client is where the MITM intercepts the connection, connects 
to your server and issues a STARTTLS itself but presents the resulting 
connection as plain text to the client.  This means that enforcing STARTTLS on 
the server side will not prevent a plain text connection through a MITM from 
the client.  But do keep in mind that if the client is configured properly to 
only connect via TLS then it will refuse the connection if it is not presented 
with a STARTTLS option that works.

So yes the safest way to go is to just use port 993, but as long as the client is not set 
to a "TLS if available" option then port 143 is also safe.


I don’t think you can call an option safe if it relies on the users to properly 
configure their client. We all know that users are usually bad at following 
instructions ;-)


Fair enough, but this attack vector can only happen if it's on a client 
that supports a downgrade option (I should hope that most don't 
nowadays, but someone did mention MacOX Mail earlier) *and* the user 
selects that option when configuring as opposed to the stricter "TLS 
only" (or equivalent) option.  At that point it still requires a MITM 
attack to downgrade the connection, and that MITM must not only be able 
to read the packets but also intercept them and present different data 
to the user.  I can see this type of attack happening in wifi 
environments and coming from ISPs that want to snoop on people's email, 
though.


As I said (and I stand by it) the safest approach is to just limit to 
port 993, but port 143 is also safe if properly configured on both the 
server and client side.



Peter

Re: identify 143 vs 993 clients

[Jean-Daniel]

> Le 31 mai 2020 à 06:09, Peter  a écrit :
> 
> On 29/05/20 11:27 pm, mj wrote:
>> Thanks to all who participated in the interesting discussion.
>> It seems my initial thought might have been best after all, and 
>> discontinuing port 143 might be the safest way proceed.
> 
> Yes and no.  Some of the attack vectors mentioned are not reasonable and it 
> really depends on the client.  Thunderbird, for example, used to have 
> settings for plain text, TLS and "TLS if available", but the latter setting 
> has not been available for some time which forces the user to choose either 
> plain text or TLS at setup time now.  This means that the user would now have 
> to change the setting in their client for a downgrade attack to work.  I 
> can't speak for all MUAs but if they similarly have removed their "TLS if 
> available" option or if the users explicitly don't pick that option (you can 
> ask them not to in your setup instructions) then that type of downgrade 
> attack cannot occur.
> 
> The other possible downgrade attack which was not mentioned but is equally 
> mitigated by the client is where the MITM intercepts the connection, connects 
> to your server and issues a STARTTLS itself but presents the resulting 
> connection as plain text to the client.  This means that enforcing STARTTLS 
> on the server side will not prevent a plain text connection through a MITM 
> from the client.  But do keep in mind that if the client is configured 
> properly to only connect via TLS then it will refuse the connection if it is 
> not presented with a STARTTLS option that works.
> 
> So yes the safest way to go is to just use port 993, but as long as the 
> client is not set to a "TLS if available" option then port 143 is also safe.

I don’t think you can call an option safe if it relies on the users to properly 
configure their client. We all know that users are usually bad at following 
instructions ;-)