On Wed, Jun 10, 2015, at 06:53 PM, Viktor Dukhovni wrote: > > -o permit_tls_clientcerts=yes > > No such parameter.
Yes, caught that. It's correctly in -o smtpd_relay_restrictions=permit_tls_clientcerts,reject Not clear how I ended up with that. Gone now. > > -o relay_clientcerts=lmdb:/etc/postfix/smarthost_clientcerts > > Check the content with "postmap -q <fingerprint> lmdb:..." > > > -o smtpd_client_restrictions= > > -o smtpd_helo_restrictions= > > -o smtpd_sender_restrictions= > > -o smtpd_recipient_restrictions= > > -o smtpd_relay_restrictions=permit_tls_clientcerts,reject > > -o smtpd_data_restrictions= > > -o smtpd_end_of_data_restrictions= > > This looks like "permit_tls_clientcerts" did not match. It turns out the problem was a missing -o tls_append_default_CA=yes The smarthost end has a self-signed cert -- facing this connection -- that's addressed in my TLS key specs, but the submitter end uses an existing commercial cert. Without that setting, I believe it wasn't getting the at the standard CA certs. In any case, working now. > > -o amavisdfeed:[127.0.0.1]:40001 > > This is surely not a valid "-o" option. Did you "postfix reload" > after changing master.cf? That setting should trigger a fatal > error, and no messages coming in at all via the service in question. > Is the client connecting to this or some other service? I marvel at what a bad copy-n-paste can do to a simple communication. It's -o content_filter=amavisfeed:[127.0.0.1]:40001 which submits to an outbound amavisd policy bank for DKIM signing. Appears to work as intended. Once I figure get DKIM key rotation on the remote, with updates to a local DNS, working. I'll start figuring out DANE. After which I think I'm to a point to start testing it all as a working whole.
