Default body template including semicolon after named property in rendered message

[c0shea]

I'm not sure why, but the {{$Message}} that is rendered in the email body is including a semicolon after the second named property from the Health Check input, even though that semicolon is not in the event payload in Seq. When our operations team receives the error email, they go to click the link, but it always fails because our email client is treating the double quote as part of the URL because it sees the semicolon (that shouldn't be there) after it.

There's no semicolon in the JSON in Seq

[KodrAus]

Hi @c0shea 👋 That's strange! It looks like you might be using an older version of the Email app. Is it possible to first try upgrading to the current 3.1.0-dev-00179 version and see if you're still seeing that additional semicolon?

[c0shea]

Thanks @KodrAus. I can't get the latest version to send an email to test the semicolon issue. It keeps writing a diagnostic event to the stream about MailKit not being able to establish a TLS connection. I'm perplexed, though, since I don't have the Require TLS checkbox enabled in the app settings. Any thoughts?

[KodrAus]

Ah, the new version of the app is stricter on SSL, so if you're using port 465 or 587 it will try to automatically establish a secure connection, even without checking the TLS box. It looks like when this is happening the mail server is returning a certificate with a different hostname.

[c0shea]

I don't understand why it would try to use SSL/TLS, though. I have the port set to 25 and don't want it to try and establish a secure connection.

[KodrAus]

Sorry @c0shea, we will also try establish a secure connection on port 25 if the mail server advertises StartTLS. I think the options here are:

• Disable StartTLS on port 25 in your mail server if it's possible.
• Remove the offending certificate.
• Reconfigure the offending certificate so that it's valid.

The first option is probably the easiest if that's possible.

[c0shea]

Ah that'll be difficult to do, as our networking team handles this for the enterprise. I'll see what I can figure out.

[MattMofDoom]

@KodrAus @c0shea PR #81 and its downstream #83 would allow the TLS behaviour to be configured in the Email+ app, but the Seq team have been understandably busy with 2021.3 so it hasn't been reviewed.

[KodrAus]

Thanks for the ping @MattMofDoom! It's on our list to review through 😅 You're right that we've had our hands a bit full with 2021.3 so haven't had the headspace to give it the attention it deserves just yet.

[MattMofDoom]

All good @KodrAus and completely understand - I definitely don't mean to be a pest, but thought a ping might be helpful 'just in case'.

[c0shea]

I narrowed down the issue. Our mail server does actually have a valid certificate that is publicly trusted by DigiCert. However, our Seq server isn't allowed to call the OCSP URLs (e.g. ocsp.digicert.com) to check for certificate revocation. Even though the certificate isn't revoked, it fails the revocation check which means no email will ever be sent. Compared to web browsers like Chrome which use an offline CRL, MailKit attempts to use the online OCSP first and not default to an offline check with the built-in Windows CRL.

I'm trying to get our networking and security teams to allow OCSP checks, but in the meantime is it possible to add an option to disable the revocation checks?

client.CheckCertificateRevocation = false;

[c0shea]

Our networking team allowed the OCSP checks so now the email sending works with the latest version of the plugin. So now back to the original issue, the semicolon is still present after the URL in the title.

[c0shea]

Turns out this is an issue with the email client we use at work (Lotus Notes). When I send an alert email to my external email address and open it using any other mail client it doesn't render a semicolon after the URL. My apologies. I should have tested this sooner. Thanks for your help!

[MattMofDoom]

@c0shea I think your point on allowing the revocation check to be disabled may be valid. There are certainly reasons that the OCSP/CRL might not be accessible from Seq.

I had previously added an option to disable certificate validation altogether, which I removed after discussion with @nblumhardt .. but I think this one might fly since it has lower impact or risk. I'll look to add it as an option in #81