We still get comments on a blog post I did 9 years ago on SMTP Debug for Domino SMTP Routing. (I’ve updated non-working links today). This got me thinking on what other SMTP config would be useful to people. Here I’m going to cover an often underused setting relating to Domino SMTP Routing.

Comment» One of our clients reported daily Notes Client crashes for some of their users after upgrading their Notes 9.x clients to 11.0.1 FP3 (and later FP4). We narrowed it down to a certain set of steps that would INTERMITTENTLY result in a crash.

For a good while now, I've been making use of the HTTPEnableConnectorHeaders notes.ini property in Domino to allow my reverse proxies to have Domino "see" the real remote system. Though this feature is coarse-grained and is best paired with some tempering, it's served me well when used on appropriately-configured servers. Unfortunately, HCL saw fit to remove this feature in 12.0.1, declaring it a security vulnerability. I don't think this made it into the release notes as such, but did eventually get patched into the "Components no longer included in this release" page for V12. Obviously, the true problem here is that it makes my blog entries retroactively less useful. However, a secondary issue is that it will damage your applications in two main ways if you were making use of these headers:

For those of us that have run Domino for a long time, one of our bragging points has been that Domino can run for a long time without needing a restart. This was especially true if we were running on System i/iSeries/AS400. Windows servers seemed less likely to have long times between restarts. Well, apparently this isn’t a great idea according to a new Defect Article from HCL Support. If Domino is running for about 248 days, the creation date of Domino documents can be incorrect if a copy-style compact or server restart isn’t performed.

This issue has been already in 12.0, but was discovered to late to be included into 12.0.1. HCL worked hard to get IF1 out ASAP. There was a hotfix already available end of the year. But IF1 take a bit longer than distributing a hofix -- there is more testing is involved.

Domino One-Touch setup with JSON format is really great stuff -- I love it since day one. But it might be a bit difficult to edit for many admins -- Even if you use an prepared template, you have to edit the JSON file in an editor to specify server name, etc. Using variables ala Helm or Ansible makes a lot of sense and if you leverage existing JSON config templates, you might get away with not editing JSON at all. Both using the {{ Variable }} syntax. But I am more used to the shell variable syntax: ${Variable}. So I implemented both.

Did you notice already that the One-Touch setup supports importing TLS Credentials for a first server setup? You can pass a *.kyr file, a PKCS#12 (*.p12, *.pfx) or *.pem file. The files can even have a password and you can mark the resulting TLS Credentials file for export with a new password! So the full import functionality added in Domino 12.0.1 CertMgr UI is exposed in One-Touch setup for ENV variable and JSON formatted setup!

Domino 12.0.1 CertMgr provides a MicroCA for testing. You can create any type of TLS web server certificate for any name. The only restriction is that the private key cannot be exported and is recreated every time you renew the certificate. It's designed as a very easy to use, simple small CA. But this is already pretty cool for internal test environments. You can even deploy the trusted root into your browsers.

Certificate management is not rocket science and it looks like we just have too complicated tooling. Why does certificate information need to be displayed that cryptic? And why does certificate conversion need to be that complicated with cryptic parameters? OpenSSL command line is the standard Swiss army knife. But why is it that complex to use? Probably because it has been written over the years and it is built by geeks for geeks .. Domino 12 comes with CertMgr and cerstore.nsf and is very easy to use. With 12.0.1 the export/import functionality can be used to convert certificates. And we are using it for customers already to convert certificates for external applications.