Possible to increase connection limit for one user only?

[Kurt Fitzner]

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?

[Kurt Fitzner]

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?

[Kurt Fitzner]

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?

[Kurt Fitzner]

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

[Kurt Fitzner]

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

[Kurt Fitzner]

 

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

[Kurt Fitzner]

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

[Kurt Fitzner]

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