Re: Downgrade dovecot if required
On 16.12.2018 17.59, Durga Prasad Malyala wrote: > Hello all, > I have version 2.3.3-2 of dovecot and could see version 2.3.4-2 > available from the repos. > How is feedback after upgrade to 2.3.4-2? Any issues? > Can I revert back to older version if I face any problems? > > Cheers/DP You can downgrade for 2.3.4 to 2.3.3 Aki
Re: ECDSA client question
On 12/16/18 7:52 AM, Tributh via dovecot wrote: Am 16.12.18 um 12:13 schrieb Michael A. Peters: Hi, for those who have adopted ECDSA, Are there still any commonly used IMAPS/POP3S clients that still can not handle ECDSA certificates? I know you can set up Dovecot dor dual cert, I am just trying to determine if there still is a real world need to. Nearly every client can handle ECDSA, but it depends on the size of the certificate. I used years ago ECDSA-384bit certificates, which covered most of the clients. It came to the point to disable RSA in that time, but than came Android7.0. This Version can only handle ECDSA-256bit certificates or RSA. The coverage of Android7.0 is still over 20%. Google reacted fast and repaired this bug in 7.1, which is still not coming to most of the phones. Cheers Torsten Wow - My phone is running Android 6, I just checked with Dad - his phone (Motorola) is running Android 7.0 - the version with the bug. We don't replace phones just because new versions are available, we replace them when they stop working, and when we do we usually get refurbished because we hate how much electronic waste is in the world. I have to admit, the tin foil hat of mine just got an alert. We know there are unexplained constants in the NIST curves including P-256 - what if NSA was partially responsible for this bug (back room deal to avoid anti-trust prosecution, similar deal with IBM was made in the 70s I believe also involving cryptography) so that Android apps that use ECDSA (beyond just the mail client, e.g. chat apps) would use P-256 for compatibility and are maybe vulnerable to MITM for the key exchange. I want Ed25519 now.
Re: ssh_dh?
On 17 December 2018 at 07:08 Aki Tuomi < aki.tu...@open-xchange.com> wrote: On 17 December 2018 at 00:30 Daniel Miller via dovecot < dovecot@dovecot.org> wrote: Don't know if this was corrected in 2.3.4 (haven't upgraded yet but didn't see it in the notes) - but in 2.3.3 I see this in my log: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssh_dh= So...either there's an undocumented feature of SSH-over-IMAP (that's Dovecot - always on the cutting edge!) or someone had a coffee shortage during a coding session... -- Daniel It's a typo. We made non-ec DH optional in 2.3.4. This means you can remove all non-ec dh crypto algos from cipherlist. This was because ec support is pretty good and generating safe dh parameters takes a very long time, so one can simply stop supporting non-ec dh based algorithms. --- Aki Tuomi And I ment in 2.3.3. --- Aki Tuomi
Re: ssh_dh?
On 17 December 2018 at 00:30 Daniel Miller via dovecot < dovecot@dovecot.org> wrote: Don't know if this was corrected in 2.3.4 (haven't upgraded yet but didn't see it in the notes) - but in 2.3.3 I see this in my log: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssh_dh= So...either there's an undocumented feature of SSH-over-IMAP (that's Dovecot - always on the cutting edge!) or someone had a coffee shortage during a coding session... -- Daniel It's a typo. We made non-ec DH optional in 2.3.4. This means you can remove all non-ec dh crypto algos from cipherlist. This was because ec support is pretty good and generating safe dh parameters takes a very long time, so one can simply stop supporting non-ec dh based algorithms. --- Aki Tuomi
Re: ssh_dh?
Daniel, as of 2.3.x, you have to create a dh.pem parameter file unless you can convert an existing parameter file: https://wiki.archlinux.org/index.php/dovecot#Generate_DH_parame ters To generate a new DH parameters file (this will take very long): # openssl dhparam -out /etc/dovecot/dh.pem 4096 then add the file to /etc/dovecot/conf.d/10-ssl.conf ssl_dh = https://security.stackexchange.com/questions/45963/diffie-hellm an-key-exchange-in-plain-english https://security.stackexchange.com/questions/94390/whats-the-pu rpose-of-dh-parameters Yes it took a very long time, indeed five hours in my case. But now it works. I took a nap and listened to Messiah while it ground away... Enjoy... :-)
RES: Sieve scripts not backed up
I got the same problem.
# When I run doveadm backup on remote host with dovecot package version
2.3.3 no sieve scripts are copied
See debug log (sieve grep):
Debug: Module loaded:
/usr/lib64/dovecot/doveadm/lib10_doveadm_sieve_plugin.so
# When I run doveadm backup on remote host with dovecot compiled from source
version 2.2.33.2 the sieve scripts are copied
See debug log:
dsync-local(usern...@domain.com.br): Debug: sieve:
Pigeonhole version 0.5.4 (60b0f48d) initializing
dsync-local(usern...@domain.com.br): Debug: sieve:
include: sieve_global is not set; it is currently not possible to include
`:global' scripts.
dsync-local(usern...@domain.com.br): Debug: sieve:
Sieve imapsieve plugin for Pigeonhole version 0.5.4 (60b0f48d) loaded
dsync-local(usern...@domain.com.br): Debug: sieve:
Sieve Extprograms plugin for Pigeonhole version 0.5.4 (60b0f48d) loaded
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: Storage path
`/data/dovecot/mailbox/domain.com.br/username/sieve' not found
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: Using active Sieve script path:
/data/dovecot/mailbox/domain.com.br/username/.dovecot.sieve
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: Using script storage path:
/data/dovecot/mailbox/domain.com.br/username/sieve
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: Using permissions from defaults: mode=0700 gid=-1
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: Created storage directory
/data/dovecot/mailbox/domain.com.br/username/sieve/tmp
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: Relative path to sieve storage in active link: sieve/
dsync-local(usern...@domain.com.br): Debug: sieve:
file storage: sync: Synchronization active
dsync-local(usern...@domain.com.br): Debug: sieve:
file script: File
`/data/dovecot/mailbox/domain.com.br/username/sieve/Filtros.sieve' not found
dsync-local(usern...@domain.com.br): Debug:
doveadm-sieve: Value missing for key
`vendor/vendor.dovecot/pvt/server/sieve/files/Filtros' (last change:
2018-12-16 23:13:07)
dsync-local(usern...@domain.com.br): Debug:
doveadm-sieve: Assigned value for key
`vendor/vendor.dovecot/pvt/server/sieve/files/Filtros' (last change:
2018-10-05 17:03:07)
dsync-local(usern...@domain.com.br): Debug: brain M:
Import INBOX: Import attribute
vendor/vendor.dovecot/pvt/server/sieve/files/Filtros: Nonexistent locally
dsync-local(usern...@domain.com.br): Debug:
doveadm-sieve: Value missing for key
`vendor/vendor.dovecot/pvt/server/sieve/default' (last change: 2018-12-16
23:13:07)
dsync-local(usern...@domain.com.br): Debug: sieve:
file script: Opened script `Filtros' from
`/data/dovecot/mailbox/domain.com.br/username/sieve/Filtros.sieve'
dsync-local(usern...@domain.com.br): Debug:
doveadm-sieve: Assigned value for key
`vendor/vendor.dovecot/pvt/server/sieve/default' (last change: 2018-10-05
17:03:07)
dsync-local(usern...@domain.com.br): Debug: brain M:
Import INBOX: Import attribute
vendor/vendor.dovecot/pvt/server/sieve/default: Nonexistent locally
Configuration are de same on both hosts.
Regards,
Ricardo
-Mensagem original-
De: dovecot [mailto:dovecot-boun...@dovecot.org] Em nome de Marc Weustink
Enviada em: terça-feira, 4 de dezembro de 2018 08:25
Para: dovecot@dovecot.org
Assunto: Sieve scripts not backed up
Hi all.
I try to backup out sieve scripts through
doveadm -o stats_writer_socket_path= backup -R -u marc -N
tcp::4191
All mail is backed up but no scripts. What am I doing wrong ?
Thanks Marc
doveconf -n
# 2.3.4 (0ecbaf23d): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.4
(60b0f48d) # OS: Linux 4.4.0-137-generic x86_64 Ubuntu 16.04.5 LTS autofs #
Hostname: xxx dict {
acl = pgsql:/etc/dovecot/dovecot-dict-sql-local.conf.ext
}
doveadm_password = # hidden, use -P to show it mail_debug = yes mail_gid =
vmail mail_home = /home/mail/backup/%n mail_location =
maildir:/home/mail/backup/%n/mail mail_uid = vmail
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 namespace Shared {
location =
maildir:/home/mail/backup/Common/mail:INDEXPVT=/home/mail/backup/%n/mail/com
mon
prefix = Shared/
separator = /
subscriptions = no
type = public
}
namespace Users {
list = children
location =
maildir:/home/mail/backup/%%n/mail:INDEXPVT=/home/mail/backup/%n/mail/shared
/%%n
prefix = Users/%%n/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
Re: ssh_dh?
Am 16.12.2018 um 23:30 schrieb Daniel Miller via dovecot: Don't know if this was corrected in 2.3.4 (haven't upgraded yet but didn't see it in the notes) - but in 2.3.3 I see this in my log: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssh_dh= So...either there's an undocumented feature of SSH-over-IMAP (that's Dovecot - always on the cutting edge!) or someone had a coffee shortage during a coding session... # doveconf -n | egrep '(2.3|_dh)' # 2.3.4 (0ecbaf23d): /etc/dovecot/dovecot.conf ssl_dh = # hidden, use -P to show it Alexander
Re: ssh_dh?
Daniel Miller via dovecot skrev den 2018-12-16 23:30: So...either there's an undocumented feature of SSH-over-IMAP (that's Dovecot - always on the cutting edge!) or someone had a coffee shortage during a coding session... its std way of drinking coffee :=) https://www.sidorenko.io/post/2014/02/secure-ssl-configuration-for-apache-postfix-dovecot/ make one for dovecot or reuse one from postfix
ssh_dh?
Don't know if this was corrected in 2.3.4 (haven't upgraded yet but didn't see it in the notes) - but in 2.3.3 I see this in my log: imap-login: Error: Diffie-Hellman key exchange requested, but no DH parameters provided. Set ssh_dh= So...either there's an undocumented feature of SSH-over-IMAP (that's Dovecot - always on the cutting edge!) or someone had a coffee shortage during a coding session... -- Daniel
Re: Upgrade to 2.3.1 has failed
Am 16.12.2018 um 22:32 schrieb Benny Pedersen via dovecot: Alexander Dalloz skrev den 2018-12-16 21:30: Am 16.12.2018 um 19:41 schrieb Tim Dickson: permissions should be 644 or 444 owned by root. The key file should even only be readable by root and not the world. 0400 would be a good choice. all ssl pem files must only be readeble from root, nothing else, so permisson 0400 is very god safety, dovecot read pem files before drop priviledges so that why it need to be so The certificate is served anyhow to clients connecting, so that file does not have to be specificly secured. Just take care it cannot be written by non root. Alexander
Re: Upgrade to 2.3.1 has failed
Alexander Dalloz skrev den 2018-12-16 21:30: Am 16.12.2018 um 19:41 schrieb Tim Dickson: permissions should be 644 or 444 owned by root. The key file should even only be readable by root and not the world. 0400 would be a good choice. all ssl pem files must only be readeble from root, nothing else, so permisson 0400 is very god safety, dovecot read pem files before drop priviledges so that why it need to be so
Re: Upgrade to 2.3.1 has failed
Tim, Daniel, Aki, all. Problem solved. Well, sort of: It is AppArmor. I disabled AppArmor based on another sufferer's experience, and I quote: https://forums.opensuse.org/showthread.php/531740-Unexpected-pe rmissions-issue-with-Dovecot I have made some progress on solving this and tracked down the problem to apparmor which is some sort of application based security system. (How I wish Linux followed KISS principals, this appears to be yet another security layer on top of the chmod/chown layer, and not an intuitive/obvious thing either...) So once again, a victim of political correctness. This was all more Scr ewtape distraction: There is nothing wrong with dovecot 3.2.1, there is nothing wrong with my "configuration", I am not being rude, but AppArmor got hosed by the OS upgrade. https://www.suse.com/documentation/sles11/book_security/data/se c_aaintro_enable.html Tomorrow is another day, I'll fight the AppArmor alligator then. In the meantime, on to that G! Woohoo! :-) Thanks again to all. Kind regards, Andy On Sun, 2018-12-16 at 18:41 +, Tim Dickson wrote: > permissions should be 644 or 444 owned by root. > if the permissions are too open, ssl/dovecot will refuse to load > them. > you may even see a message about it if you have verbose messages/ > check your sys logs. > I had this problem once with certs that checked out fine, correct < > in dovcot config but didn't load. > chmod 644 /etc/ssl/certs/dovecot.cert /etc/ssl/private/dovecot.key > fixed the problem > regards, Tim > > On 16/12/2018 14:33, C. Andrews Lavarre wrote: > > For what it's worth, this gives the server an A: > > https://www.ssllabs.com/ssltest/analyze.html?d=mail.privustech. > > com > > > > So there is no problem with the certificates and key... > > > > Thanks again. > > > > On Sun, 2018-12-16 at 09:19 -0500, C. Andrews Lavarre wrote: > > > So it's something else. >
Re: Upgrade to 2.3.1 has failed
Am 16.12.2018 um 19:41 schrieb Tim Dickson: permissions should be 644 or 444 owned by root. The key file should even only be readable by root and not the world. 0400 would be a good choice. Alexander
Re: Bug in IDLE implementation for virtual mailbox
On 16 Dec 2018, at 21.26, Pali Rohár wrote: > > Hello! > > I found bug in Dovecot's IDLE implementation when virtual mailbox is in > use. IDLE does not notify about new emails when email appears in newly > created mailbox and IDLE was issued in virtual folder which matches "*" > wildcard and that mailbox was created after opening virtual mailbox. It actually has nothing to do with IDLE specifically. It's just that the virtual storage code doesn't try to look for new folders after the virtual mailbox is opened. > To get notifications, it is needed to re-open that "All" mailbox again. Right. I don't think this is going to be fixed anytime soon. Quite a lot of effort and it can be worked around.
Bug in IDLE implementation for virtual mailbox
Hello! I found bug in Dovecot's IDLE implementation when virtual mailbox is in use. IDLE does not notify about new emails when email appears in newly created mailbox and IDLE was issued in virtual folder which matches "*" wildcard and that mailbox was created after opening virtual mailbox. This problem is present in version 2.2.34 which is available in Debian Stretch system with backports. Reproducer: 1. Create virtual "All" mailbox in Gmail-like style: $ cat All/dovecot-virtual * -Drafts -Spam -Trash ALL 2. Ensure that (real non-virtual) mailbox "Test" does not exist. 3. Create sieve rule which deliver some email to "Test" mailbox. require [ "fileinto", "mailbox" ]; ... fileinto :create "Test"; 4. Open dovecot imap connection, select virtual "All" mailbox and then enter IDLE command. 4. Send email which matches that sieve filter. Email will be processed by dovecot sieve. As "Test" mailbox does not exist, dovecot sieve would first create it and then deliver email into it. Now dovecot imap should notify IDLE client that new message into virtual "All" mailbox was delivered (as it collects emails from all - * - mailboxes). But dovecot for some unknown reason does not notify via IDLE that there is a new email. To get notifications, it is needed to re-open that "All" mailbox again. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Re: Upgrade to 2.3.1 has failed
permissions should be 644 or 444 owned by root. if the permissions are too open, ssl/dovecot will refuse to load them. you may even see a message about it if you have verbose messages/ check your sys logs. I had this problem once with certs that checked out fine, correct < in dovcot config but didn't load. chmod 644 /etc/ssl/certs/dovecot.cert /etc/ssl/private/dovecot.key fixed the problem regards, Tim On 16/12/2018 14:33, C. Andrews Lavarre wrote: For what it's worth, this gives the server an A: https://www.ssllabs.com/ssltest/analyze.html?d=mail.privustech.com So there is no problem with the certificates and key... Thanks again. On Sun, 2018-12-16 at 09:19 -0500, C. Andrews Lavarre wrote: So it's something else.
Downgrade dovecot if required
Hello all, I have version 2.3.3-2 of dovecot and could see version 2.3.4-2 available from the repos. How is feedback after upgrade to 2.3.4-2? Any issues? Can I revert back to older version if I face any problems? Cheers/DP
Re: ECDSA client question
Am 16.12.18 um 12:13 schrieb Michael A. Peters: > Hi, for those who have adopted ECDSA, > > Are there still any commonly used IMAPS/POP3S clients that still can not > handle ECDSA certificates? > > I know you can set up Dovecot dor dual cert, I am just trying to > determine if there still is a real world need to. Nearly every client can handle ECDSA, but it depends on the size of the certificate. I used years ago ECDSA-384bit certificates, which covered most of the clients. It came to the point to disable RSA in that time, but than came Android7.0. This Version can only handle ECDSA-256bit certificates or RSA. The coverage of Android7.0 is still over 20%. Google reacted fast and repaired this bug in 7.1, which is still not coming to most of the phones. Cheers Torsten
Re: Upgrade to 2.3.1 has failed
As a LetsEncrypt user myself, I have: ssl_cert = So nothing further should be required. You say Dovecot fails to start - have you tried simply executing "dovecot -F"? Daniel On 12/16/2018 6:19 AM, C. Andrews Lavarre wrote: Phil hi. Thank you for explaining what the symbol does... so it is like the BASH *from* symbol. OK.That is new information. So without it dovecot reads the *path/to/file* as if it were a hashed cert, which of course doesn't work. So *with* the symbol dovecot tries to follow the path to read the cert but for some reason cannot read it. Now, that is curious, since I can *cat* the path/to/file and read the cert or key... Now, while the /path/to/file permission is presently *root:root 0777 *(yes, I know 0777 is not good, but I was trying to eliminate any prevention to reading it)**it is actually a soft link to yet another file. Let'sEncrypt has to be renewed every so often so the cert engine (*certbot*) recreates the softlink to the new cert so that we don't need to edit *10-ssl.conf*. So I have entered the actual full path/to/file for the cert and key (not the softlinks) to eliminate that possibility, buty it didn't help. So it's something else. As you say, focus on the problem: Simply put, why can 2.3.1 not read a file while we can list and print out (*ls, cat*) the file? What changed in that regard from 2.2.x to 2.3.1? I'm very grateful for the time folks have spent on this, including my own time. I'm not being rude, just factual. This is what is happening. But "something is wrong with your configuration", while equally factual, is also equally ineffective. OTOH, in my experience factually describing an anomaly can lead to someone wondering why it might be, and if they are more knowledgeable of the inner workings of the system be better able to understand why that might be. For example, I didn't know anything about AppArmor before, now I do, have gone down that rabbit hole, and seem to be able to say, nope, that's not the problem. So now I can move on to checking out something else. Similarly, under BASH the path/to/files are all correct and I can read them from the command line. And 2.2.x didn't have any problem with them. So why might 2.3.1 not be able to read them? So we all need to leave this alone, for now. I'll work along, and when/if I figure it out shall return to report. I'm sure it's something simple: Easy when you know how. :-) Thanks again. Andy On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote: Andy, This is just rude. You have been told multiple times that the less-than symbol is required to read the certificate from the file. Otherwise, the filename is parsed as if it is the certificate itself. Which yields garbage. If dovecot can't read that file, it is *not* dovecot's fault. You are simply not going to succeed until *you* figure out what security differences you have in your new installation. So dovecot can read the files. Every single attempt to connect via openssh depends on dovecot reading your certificate and key files. They are pointless exercises until dovecot actually loads your files. Focus on the real problem if you wish to fix your service. On 12/15/18 5:12 PM, C. Andrews Lavarre wrote: Alexander, Thanks, as described before, if I include the "<" then Dovecot fails to start at all. Thank you again for your time. I have forwarded my latest to Aki to the group. Regards, Phil
Re: Upgrade to 2.3.1 has failed
For what it's worth, this gives the server an A: https://www.ssllabs.com/ssltest/analyze.html?d=mail.privustech. com So there is no problem with the certificates and key... Thanks again. On Sun, 2018-12-16 at 09:19 -0500, C. Andrews Lavarre wrote: > So it's something else.
Re: Upgrade to 2.3.1 has failed
Phil hi. Thank you for explaining what the symbol does... so it is like the BASH from symbol. OK.That is new information. So without it dovecot reads the path/to/file as if it were a hashed cert, which of course doesn't work. So with the symbol dovecot tries to follow the path to read the cert but for some reason cannot read it. Now, that is curious, since I can cat the path/to/file and read the cert or key... Now, while the /path/to/file permission is presently root:root 0777 (y es, I know 0777 is not good, but I was trying to eliminate any prevention to reading it) it is actually a soft link to yet another file. Let'sEncrypt has to be renewed every so often so the cert engine (certbot) recreates the softlink to the new cert so that we don't need to edit 10-ssl.conf. So I have entered the actual full path/to/file for the cert and key (not the softlinks) to eliminate that possibility, buty it didn't help. So it's something else. As you say, focus on the problem: Simply put, why can 2.3.1 not read a file while we can list and print out (ls, cat) the file? What changed in that regard from 2.2.x to 2.3.1? I'm very grateful for the time folks have spent on this, including my own time. I'm not being rude, just factual. This is what is happening. But "something is wrong with your configuration", while equally factual, is also equally ineffective. OTOH, in my experience factually describing an anomaly can lead to someone wondering why it might be, and if they are more knowledgeable of the inner workings of the system be better able to understand why that might be. For example, I didn't know anything about AppArmor before, now I do, have gone down that rabbit hole, and seem to be able to say, nope, that's not the problem. So now I can move on to checking out something else. Similarly, under BASH the path/to/files are all correct and I can read them from the command line. And 2.2.x didn't have any problem with them. So why might 2.3.1 not be able to read them? So we all need to leave this alone, for now. I'll work along, and when/if I figure it out shall return to report. I'm sure it's something simple: Easy when you know how. :-) Thanks again. Andy On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote: > Andy, > > This is just rude. You have been told multiple times that the less- > than > symbol is required to read the certificate from the file. Otherwise, > the filename is parsed as if it is the certificate itself. Which > yields > garbage. > > If dovecot can't read that file, it is *not* dovecot's fault. You > are > simply not going to succeed until *you* figure out what security > differences you have in your new installation. So dovecot can read > the > files. Every single attempt to connect via openssh depends on > dovecot > reading your certificate and key files. They are pointless exercises > until dovecot actually loads your files. Focus on the real problem > if > you wish to fix your service. > > On 12/15/18 5:12 PM, C. Andrews Lavarre wrote: > > > > Alexander, Thanks, as described before, if I include the "<" then > > Dovecot fails to start at all. > > > > Thank you again for your time. I have forwarded my latest to Aki to > > the > > group. > > Regards, > > Phil
Re: Upgrade to 2.3.1 has failed
Andy, This is just rude. You have been told multiple times that the less-than symbol is required to read the certificate from the file. Otherwise, the filename is parsed as if it is the certificate itself. Which yields garbage. If dovecot can't read that file, it is *not* dovecot's fault. You are simply not going to succeed until *you* figure out what security differences you have in your new installation. So dovecot can read the files. Every single attempt to connect via openssh depends on dovecot reading your certificate and key files. They are pointless exercises until dovecot actually loads your files. Focus on the real problem if you wish to fix your service. On 12/15/18 5:12 PM, C. Andrews Lavarre wrote: > Alexander, Thanks, as described before, if I include the "<" then > Dovecot fails to start at all. > > Thank you again for your time. I have forwarded my latest to Aki to the > group. Regards, Phil
Plugins mailboxalias subfolders
This plugin does not work anymore when subfolders are created. https://wiki2.dovecot.org/Plugins/MailboxAlias
ECDSA client question
Hi, for those who have adopted ECDSA, Are there still any commonly used IMAPS/POP3S clients that still can not handle ECDSA certificates? I know you can set up Dovecot dor dual cert, I am just trying to determine if there still is a real world need to.
Re: mailbox locking
Victor Sudakov wrote: I use exim's appendfile transport, procmail and a local mutt on my system, they all (to my knowledge) use lockfiles when working with mboxes. [vas@adm2 ~] procmail -v | & grep Locking Locking strategies: dotlocking, lockf() vas@adm2 ~] mutt -v|grep -i lock Configure options: '--disable-fcntl' '--with-ssl=/usr' '--with-docdir=/usr/local/share/doc/mutt' '--sysconfdir=/usr/local/etc' '--enable-external-dotlock' '--enable-pop' '--enable-imap' '--enable-compressed' '--enable-sidebar' '--disable-flock' '--disable-gpgme' '--with-gss=/usr' 'CFLAGS=-I/usr/include -O2 -pipe -fstack-protector -fno-strict-aliasing ' 'LDFLAGS=-L/usr/lib -L/usr/local/lib -Wl,-rpath=/usr/local/lib:/usr/lib -ltinfow -fstack-protector ' 'LIBS=-lkrb5 -lgssapi -lgssapi_krb5 ' 'KRB5CONFIG=/usr/bin/krb5-config' '--without-bdb' '--without-kyotocabinet' '--disable-hcache' '--without-tokyocabinet' '--with-libiconv-prefix=/usr/local' '--with-idn2' '--enable-locales-fix' '--disable-nls' '--with-sasl=/usr/local' '--enable-smtp' '--prefix=/usr/local' '--localstatedir=/var' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd11.2' 'build_alias=amd64-portbld-freebsd11.2' 'CC=cc -I/usr/local/include' 'CPPFLAGS=' 'CPP=cpp' -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL -USE_FLOCK [vas@adm2 ~] # exim -bP transport local_delivery | grep -i lock lock_fcntl_timeout = 0s lock_flock_timeout = 0s lock_interval = 3s lock_retries = 10 lockfile_mode = 0600 lockfile_timeout = 30m use_fcntl_lock no_use_flock_lock use_lockfile no_use_mbx_lock However, `doveconf | grep lock` says dotlock_use_excl = yes lock_method = fcntl mail_max_lock_timeout = 0 mbox_dotlock_change_timeout = 2 mins mbox_lock_timeout = 5 mins mbox_read_locks = fcntl mbox_write_locks = dotlock fcntl pop3_lock_session = no Do I need to change anything in dovecot's default locking setup? Does it still use lockfiles on mboxes or not? There are some contradictory parameters IMHO. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Feature request SCRAM-SHA-256
> On 16 December 2018 at 11:06 Tributh wrote: > > > > > Am 16.12.18 um 09:42 schrieb Aki Tuomi: > > > >> On 16 December 2018 at 10:27 Tributh via dovecot > >> wrote: > >> > >> > >> Hi, > >> is that here the right place to make feature requests? > >> > >> dovecot supports as authentication mechanism > >> SCRAM-SHA-1 from RFC 5802 > >> which was updated to > >> SCRAM-SHA-256 in RFC 7677 > >> > >> Can SCRAM-SHA-256 be added to the authentication mechanisms? > >> > >> I would not like to request, that SCRAM-SHA-1 will be exchanged by > >> SCRAM-SHA-256, since several applications only support SCRAM-SHA-1 > >> > >> Regards > >> > >> Torsten > > > > Hi! > > > > Adding this is possible, it can even be done as a separate plugin. But I > > have to ask, why? Do you actually have clients that support this? > > > > Aki > > > Hi Aki, > let me first answer the second question. > Sadly I have no client which supports it, yet. > Here we have a chicken or the egg causality dilemma. > There was some communication with mail-client developers which stated > that they would start developing it, when they have a publicly usable > server to test against. > Now I hope that the most common IMAP server could be the one, which > gives this possibility. > Sadly, most communication is not publicly available. > > In the past CRAM-MD5 was very popular. When the insecurity came out, > everything just shifted to TLS, but that prevented not from sending a > plain password now. If a malicious actor is able to change DNS/TLS > endpoints, he will receive the plain passwords immediately. > I am not the expert in explaining how such an actor could do this. I > just wanted to have possibilities for everybody to prevent this possible > exposure of a plain password, which could than easily used abusively. > > I just hope for better security in the future. > > Regards Torsten > > We'll see if this could be added. Aki
Re: Feature request SCRAM-SHA-256
Am 16.12.18 um 09:42 schrieb Aki Tuomi: > >> On 16 December 2018 at 10:27 Tributh via dovecot wrote: >> >> >> Hi, >> is that here the right place to make feature requests? >> >> dovecot supports as authentication mechanism >> SCRAM-SHA-1 from RFC 5802 >> which was updated to >> SCRAM-SHA-256 in RFC 7677 >> >> Can SCRAM-SHA-256 be added to the authentication mechanisms? >> >> I would not like to request, that SCRAM-SHA-1 will be exchanged by >> SCRAM-SHA-256, since several applications only support SCRAM-SHA-1 >> >> Regards >> >> Torsten > > Hi! > > Adding this is possible, it can even be done as a separate plugin. But I have > to ask, why? Do you actually have clients that support this? > > Aki > Hi Aki, let me first answer the second question. Sadly I have no client which supports it, yet. Here we have a chicken or the egg causality dilemma. There was some communication with mail-client developers which stated that they would start developing it, when they have a publicly usable server to test against. Now I hope that the most common IMAP server could be the one, which gives this possibility. Sadly, most communication is not publicly available. In the past CRAM-MD5 was very popular. When the insecurity came out, everything just shifted to TLS, but that prevented not from sending a plain password now. If a malicious actor is able to change DNS/TLS endpoints, he will receive the plain passwords immediately. I am not the expert in explaining how such an actor could do this. I just wanted to have possibilities for everybody to prevent this possible exposure of a plain password, which could than easily used abusively. I just hope for better security in the future. Regards Torsten
Re: Feature request SCRAM-SHA-256
> On 16 December 2018 at 10:27 Tributh via dovecot wrote: > > > Hi, > is that here the right place to make feature requests? > > dovecot supports as authentication mechanism > SCRAM-SHA-1 from RFC 5802 > which was updated to > SCRAM-SHA-256 in RFC 7677 > > Can SCRAM-SHA-256 be added to the authentication mechanisms? > > I would not like to request, that SCRAM-SHA-1 will be exchanged by > SCRAM-SHA-256, since several applications only support SCRAM-SHA-1 > > Regards > > Torsten Hi! Adding this is possible, it can even be done as a separate plugin. But I have to ask, why? Do you actually have clients that support this? Aki
Feature request SCRAM-SHA-256
Hi, is that here the right place to make feature requests? dovecot supports as authentication mechanism SCRAM-SHA-1 from RFC 5802 which was updated to SCRAM-SHA-256 in RFC 7677 Can SCRAM-SHA-256 be added to the authentication mechanisms? I would not like to request, that SCRAM-SHA-1 will be exchanged by SCRAM-SHA-256, since several applications only support SCRAM-SHA-1 Regards Torsten
