Re: Dovecot refuses to install/run on machine without IPv6
On 2024-08-07 07:23, Aki Tuomi wrote: On 07/08/2024 13:05 EEST Peter via dovecot wrote: On 7/08/24 07:08, Kurt Fitzner via dovecot wrote: Hi, I just tried to install Dovecot (version 2.3.19.1 9b53102964) on a Debian 12 server I'm building. It failed because Dovecot's default listen address is explicitly "*, ::" and it appears to have no logic to determine if there actually is an IPv6-enabled interface or that IPv6 is enabled on the target machine before it tries to listen on it. If dovecot wants to listen on IPv6 by default, that's neither here nor there, but if this is default behaviour it should check first. How does this affect installation? I would not expect dovecot to work out of the box without having to change at least some settings to suit my specific installation. Most servers nowadays are dual stack so *, :: makes sense as a default. In your case you simply need to edit your dovecot.conf and add (or uncomment) listen = *. I'm curious if it's the same behaviour for machines without IPv4. Machines without IPv4 enabled are even more of a rarity than ones without IPv6 nowadays. I think it's bad practice, however ubiquitous both are right now, to assume either. Just want to point out that the OP problem is that he has AF_INET6 disabled. Dovecot is totaly happy to start if there is ::1 available on the system. Notably this usually happens with Docker or some systems where AF_INET6 has been intentionally disabled. In these cases it's imo the operator's responsibility to change the listen line to match their preference, and in dovecot's Docker images, we have changed listen to just * for the docker reason. It does not require you to have *publicly routable* ipv4 or ipv6, just localhost will suffice. Setting a default listen address to an address family that you don't know exists on target machines is fine, as long as it's a not-fatal failure if that address family doesn't exist. Admitedly the installation failure I experienced was because of a Debianism, which wants to start the service at install time. I'm not actually sure if the failure was right at the end of the install, or if there were other installation steps after the failure that were aborted. Rather than dig through the install scripts (and out of an abundance of caution) I simply tore out Dovecott, enabled IPv6, and then reinstalled it just to make sure all installation steps were followed. I can't think of another Linux service anywhere that sets a default listen to adapters on an address family and then makes it a fatal error if that family doesn't exist. One shouldn't have to enable an address family one doesn't use in order to get a service to install properly. Please either make this a non-fatal error, or by default have Dovecot not listen on anything and require the user to explicitly set the listen adapters in the config file. Don't you think that a warning in the journal is the more appropriate level of response to a default listen adapter not existing? Thanks ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Dovecot refuses to install/run on machine without IPv6
Hi, I just tried to install Dovecot (version 2.3.19.1 9b53102964) on a Debian 12 server I'm building. It failed because Dovecot's default listen address is explicitly "*, ::" and it appears to have no logic to determine if there actually is an IPv6-enabled interface or that IPv6 is enabled on the target machine before it tries to listen on it. If dovecot wants to listen on IPv6 by default, that's neither here nor there, but if this is default behaviour it should check first. I'm curious if it's the same behaviour for machines without IPv4. Kurt Fitzner ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Possible to increase connection limit for one user only?
I run a medium-sized virtual domain email server for about 15 domains. I also use it myself and have 3 or 4 devices using imap. I am often using a VPN to connect to my home network, which makes all my connections appear to come from one IP. I want to increase mail_max_userip_connections just for myself only so I'm not opening up my server to abuse. Is this possible?
How to set lmtp delivery file/directory permissions?
I have my postfix/dovecot virtual mail system essentially (otherwise) configured where Postfix is calling Dovecot for its virtual transport: virtual_transport = lmtp:unix:private/dovecot-lmtp But I can't for the life of me see how to change the file permissions dovecot uses to create maildir folders and files. I looked at the maildir [1], lmtp [2], and other documents and they are either silent on permissions or seem to reference a shared mail permissions document [3] that claims file and folder permissions are inherited. I want all files dovecot creates to be made accessible to the mail group. Please tell me this wasn't hard-coded a la postfix. Thanks, Kurt Fitzner Links: -- [1] https://wiki.dovecot.org/MailboxFormat/Maildir#Maildir_and_filesystems [2] https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/ [3] https://doc.dovecot.org/admin_manual/filesystem_permission/
Re: How to configure Dovecot to disable NIST's curves and still rertain EECDH?
My opinion is that security by RFC is not security, it's mommy medicine. Standards have had a terrible time keeping up with security realities. NITS's curves leak side channel information all over the place. I don't have details on what implementations are set to calculate the NIST curves in constant time, and that's not an easy feat to do anyway so I don't want to depend on implementations that say they are actually doing it the right way. Frankly I can't be bothered to keep up with that. There are better curves TODAY, so yes I intend to use them if I can find a way. Otherwise, I'll just keep EECDH disabled. I have EDH now, and I've not yet run into a client that doesn't support it. I want EECDH, but I won't use it without safe curves. I'm confident that EECDH with safe curves and a second choice of EDH will support any clients that are worth using. OpenSSL supports X25519, and that is half the battle. Is there a way to change the curve selection in Dovecot? On 2018-12-19 01:49, Tributh via dovecot wrote: > Do you really plan to do this? > RFC 8446 section 9.1: > A TLS-compliant application MUST support key exchange with secp256r1 > (NIST P-256) and SHOULD support key exchange with X25519 > > I think your idea could be not future proved. > > Beside that, how many mail-clients will remain usable with this cipher > selection? > > Torsten
How to configure Dovecot to disable NIST's curves and still rertain EECDH?
I am interested in configuring Dovecot's TLS so as to retain forward secrecy, but eliminate all of NIST's elliptic curves. Besides being subject to side channel attacks [1], in some quarters there is a general distrust of NIST's curves and any of their other cryptographic primitives after the Dual EC DRBG debacle. >From what I can tell, the following will prevent the use of NIST's curves (along with other dangerous primitives) in Dovecot, but this is accomplished by simply disabling EECDH entirely. ssl_cipher_list = HIGH:!DSS:!EECDH:!ECDH:!SHA1:!aNULL:!eNULL:@STRENGTH This should still retain forward secrecy through the use of EDH, but this doesn't leave much in the way of allowable algorithms on my server: $ openssl ciphers -V 'HIGH:!DSS:!EECDH:!ECDH:!SHA1:!aNULL:!eNULL:@STRENGTH' 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 Is there a better way to do this? Is there a way to disable only the suspect NIST curves and still retain EECDH but with side-channel safe curves like X25519? Thanks, Kurt Fitzner Links: -- [1] https://blog.cr.yp.to/20140323-ecdsa.html
Re: Automatic DB password hash scheme selection
Hi all,
Is there a way to get dovecot to recognize arbitrary password hash
schemes when looking up a password in a database? I originally set up
with #default_pass_scheme = MD5, and I would like to migrate to
SHA512.
Is this possible currently?
Thanks,
Kurt
Hi!
Prefix with {SCHEME}.
Hi Aki,
Thanks for the tip. This works, but when implementing it I discovered
that just setting the password type generically to 'CRYPT' will let
Dovecott use the built-in OS crypt decoding of the scheme number already
encoded in the password. It now automatically detects MD5, SHA256, and
SHA512. If my Linux distribution supported blowfish it would support
that too.
Automatic DB password hash scheme selection
Hi all, Is there a way to get dovecot to recognize arbitrary password hash schemes when looking up a password in a database? I originally set up with #default_pass_scheme = MD5, and I would like to migrate to SHA512. Seeing as the scheme is actually stored in the password column along with the password in the format $__$__$__, it seems to me that dovecot should be able to look at the scheme number and simply do the right thing. If this is possible, then migrating passwords over would be much easier, since people will still be able to log in with their old MD5-hashed password and the changer can be set up to hash with the new method. Is this possible currently? Thanks, Kurt
Re: Sub addressing delimiters
On 2016-08-24 09:20, Tanstaafl wrote: Objection: assumes facts not in evidence. This is the way it is supposed to work now in dovecot, so, either it is now broken, was always broken ... or you are not doing it right. But we'd need to see your config to make that determination... How about source tree? I now present my case to the court. :) 1) The changelog: 2009-11-10 * src/lib-lda/lda-settings.c, src/lmtp/commands.c: recipient_delimiter: Allow multi-character delimiters. [0d659ac4656d] (taken from the change log in 2.2.13 since this entry is no longer visible in the change log in 2.2.13. There are no other relevant entries referencing recipient_delimiter in 2.2.25. This isn't a sure indication, but it seems to me to imply what the intention was. 2) rcpt_address_parse() in lmtp/commands.c domain = strchr(address, '@'); p = strstr(address, client->unexpanded_lda_set->recipient_delimiter); This function is looking for the domain separation with strchr(), but looking for the username and detail separation with strstr(). To treat recipient_delimiter as a list of single-character delimiters you can pick from, then you'd need to loop through recipient_delimiter and use strchr() for each character. 3) Right now I have recipient_delimiter set to + and it works. When I tried to set it to +_ to use either a plus or underscore, then sent test email to name_det...@domain.org it caused an error, but name+_det...@domain.org was delivered correctly. Reversing the order in dovecot's recipient_delimiter setting to _+ caused only name_+det...@domain.org to work in test emails. Switching to the behaviour where recipient_delimiter is treated as a list of usable delimiters might not be totally trivial. If you look in address_add_detail() in lmtp/commands.c you'll see why. This function is trying to recreate a complete email address from the recipient, the detail, and domain but since the delimiter that was used when the username/detail was split isn't saved, it simply uses the multi-character recipient_delimiter setting in its entirety. Kurt
Sub addressing delimiters
Hello, There is a disconnect between the way Postfix handles recipient_delimiter and the way Dovecot handles it. For Postfix, it is a set of delimiters that can each individually be used to separate the address from the . In Dovecot, having multiple characters in recipient_delimiters simply makes it a multi-character single delimiter. For my purposes, the Postfix method is much more versatile. Extra delimiters can be added without breaking the way users currently have delimiters. I am wondering what the odds are of reconciling the two approaches, hopefully in favour of the Postfix one. Failing a switch to the other behaviour, is it possible to add the Postfix method as an option? Would a patch for either of these be accepted? Thanks, Kurt Fitzner
