To follow up on my previous email,

It seems the lmtp deamon does NOT support ssl_ca selection based on remote IP. It also does NOT seem to support authorization.

The solution I arrived at was to create a separate CA, used solely for the purpose of authorizing LDAP clients.

openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:4096 -out /etc/ssl/private/ca_dovecot_lmtps.key
openssl req -x509 -new -subj '/CN=Dovecot LMTP Authorization CA' -key /etc/ssl/private/ca_dovecot_lmtps.key -nodes -sha256 -days 3650 -addext 'keyUsage=keyCertSign,cRLSign' -out /etc/ssl/private/ca_dovecot_lmtps.pem

This CA can then be used to sign certificates for LMTP clients to use when delivering mail.

export lmtpsrc=msa
openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 -out /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.key
openssl req -new -nodes -key /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.key -sha256 -out /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.csr -subj "/CN=${lmtpsrc}.example.com"
cat <<EOF >/etc/ssl/private/_lmtp.${lmtpsrc}.example.com.ext
basicConstraints = critical, CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:${lmtpsrc}.example.com
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
EOF
openssl x509 -req -CA /etc/ssl/private/ca_dovecot_lmtp.pem -CAkey /etc/ssl/private/ca_dovecot_lmtp.key -sha256 -days 3650 -in /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.csr -extfile /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.ext -out /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.pem

The Dovecot configuration looks like this

protocol lmtp {
  mail_uid = nobody
  auth_ssl_require_client_cert = yes
  ssl_verify_client_cert = yes
  ssl_ca = </etc/ssl/private/ca_dovecot_lmtps.pem

  ssl = required
  ssl_cert = </etc/ssl/mda.example.com-chain.pem
  ssl_key = </etc/ssl/private/mda.example.com.key
  ssl_require_crl = no
}

This solution seems secure and manageable so long as the number of LMTP sources stays small, but overall, feels very unsatisfactory.

I would regard Dovecot's inability to inspect the LMTP certificate's subject name as a BUG that should be prioritized.

As it stands, I would not be surprised to find real-world deployments of Dovecot that are insecure, as _ANY_ host with a valid certificate could originate mail.

As a quick illustration, I created another certificate with an invalid name from my "/CN=Dovecot LMTP Authorization CA" authority. The mail was accepted without complaint. In "normal" setups, a certificate from any public CA would be accepted.

Feb 11 14:29:52 imaps mail.info dovecot: lmtp(16386): Received valid SSL certificate: /CN=Dovecot LMTP Authorization CA
Feb 11 14:29:52 imaps mail.info dovecot: lmtp(16386): Received valid SSL certificate: /CN=evil.example.com
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read client certificate
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read certificate verify
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read finished
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x20, ret=1: SSLv3/TLS write session ticket
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket
Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully