Shouldn't fail when keys aren't owned by root

[clarfonthey]

These output as warnings like warn: /path/to/key: not owned by uid 0, but then result in a hard error, preventing the keys from being loaded whenever they aren't owned by UID 0 (root). This is especially weird because it happens for the public key files as well, which don't have to have any particularly strict permissions since they're public keys, and the program verifies that they match the private keys anyway.

I personally have an ACME client running under the user acme, and thus all the certificate files are owned by acme with group smtpd. I really don't think this is an error, especially considering how the smtpd process switches down to the smtpd user after it loads everything. I would personally run it as that user to begin with if it weren't required by the daemon.

I would just make a change that removes the goto fail but I figure that there's a reason for this change that I'm maybe not understanding, which is why I'm filing an issue instead.

[bitfehler]

Given that this issue hasn't gotten any traction, may I suggest a (Linux only, sorry) workaround for those who find this issue like me: use an idmapped bind mount to someplace where smtpd can pick it up. Example (I am using uacme, but the concept should be clear):

mount -o bind,ro,X-mount.idmap=b:500:0:1 /home/ssl/uacme /etc/smtpd/uacme

Where 500 is the uid/gid of my system's uacme user. This creates a read-only bind mount in /etc/smtpd/uacme where all files that are actually owned by uid 500 appear as owned by uid 0 (same for gid). Then use that directory in smtpd.conf, works. See man mount for details (search for "idmap").