Support Untrusted Certificates

[Jaben]

First of all, thanks for Seq and all its awesomeness.

We don't support secure (SSL/TLS) servers internally for sending emails. The latest version will check if TLS is available and "switch to it." But that fails because our certificates are self-signed. I realize this is a company IT problem -- but I doubt I'm the only one with this problem.

Possible Options for the plugin:

• Could support a "Force Insecure" option -- SecureSocketOptions.None option.
• Could support disabling SSL Verification option e.g.: An error occurred while attempting to establish an SSL or TLS connection jstedfast/MailKit#1227

I'm happy to implement these solutions and make a PR. But I don't want to waste time if you don't want the plugin going down this road, @nblumhardt.

For now, I'm keeping the plugin version on v3.0.0.

Thanks!

[nblumhardt]

Thanks for the heads-up, @Jaben.

I'm assuming that trusting the self-signed cert on the Seq server isn't an option for you? That's generally the ideal approach, but understandably not always practical.

@MattMofDoom spotted this issue earlier, and kindly wrote up some thoughts in #81 (comment); I think his suggestion to add UseTlsWhenAvailable is similar to your "Force Insecure".

I'd rather avoid an option to disable cert validation, so exploring that avenue first.....

The pair-of-checkboxes approach detracts from usability a bit, and leaves us having to communicate semantics carefully to the user; perhaps we should look at what's required to move this setting from a Boolean to an enum/select (effectively matching SecureSocketOptions)?

The options would be something like "Always", "When Available", and "Never" (though we could also consider explicit "On Connect"/"STARTTLS" options).

Seq already has support for this type of app setting; the main stumbling block is migrating existing instances of the app across. I might just quickly review what options we have, there, and loop back.... 🤔

[MattMofDoom]

@nblumhardt @Jaben You rang? 😂

By way of quick recap - we agreed in a previous discussion (#77) on not disabling SSL validation, and I withdrew an earlier pull request for that. I don't think we need to go back there, although my testing around #81 showed that there were certainly scenarios where the current SecureSocketOptions.StartTlsWhenAvailable is problematic and users will need to configure settings like SecureSocketOptions.None.

I think it's fundamental that we need an ability to disable TLS altogether - we lost that with the move to MailKit, hence why I was adding UseTlsWhenAvailable to reinstate the old SmtpClient behaviour and also duplicate the behaviour of the simpler UseSsl boolean in MailKit.

I definitely prefer an enum/select that matches SecureSocketOptions - that will get us to where I was trying to go with dual tickboxes. I wasn't aware that we could provide an select dropdown (didn't see it in the input types) or I'd probably have done it in the PR 😊

I also like this with reference to #81's overall enhancements for multiple servers and delivery via MX lookup in DNS, since fine grained control over TLS becomes more important.

Suggestion for how to migrate -

1. We preserve the 'old' EnableSsl setting, but stop presenting it to the UI
2. We add a new EnableTls setting based on the enum, as a nullable setting
3. First run, we find that EnableSsl is not null and EnableTls is null, so we migrate to the appropriate enum setting
4. Future runs will ignore EnableSsl because EnableTls is not null

@nblumhardt This should have only minimal impact to #81 and #83 since I'd consolidated the settings to a single GetSocketOptions call.

Cheers,

Matt

[MattMofDoom]

@nblumhardt Further thought and kind of consistent with #81 ... If both the EnableTls nullable enum AND the now-hidden EnableSsl bool? are null, then we use SecureSocketOptions.Auto, which again should have some consistency with MailKit behaviours observed. This covers a scenario that someone adds a new instance and does not configure the EnableTls enum.

Hell, I'd adjust the PR to this now if I could (or knew how to) expose the select dropdown input type 😂

[MattMofDoom]

@nblumhardt So I got off my backside and figured out where you had implemented the enum dropdown select functionality. The only thing I couldn't figure out was adding display names to the enums - just not sure if your comment on datalust/seqcli#160 accurately reflects that there should be a [Display{..}] attribute.

I have implemented the migration from EnableSsl and added appropriate tests - all working. I did preserve the implicit TLS behaviour when the port is set to 465. We map an enum to SecureSocketOptions which allows it to be readily cast - this was because I was trying to implement the Display attribute, and I've left it as is because we can always circle back if/when a friendly display name is possible.

I made a temporary Nuget package available for my dev purposes and was able to do some testing around the TLS options - as well as the DNS delivery (failed because my ISP blocks outbound SMTP, boo, but the resolution and delivery attempt works!). The enhanced logging is helpful too.

Hoping this fits the bill!

[Jaben]

I'm assuming that trusting the self-signed cert on the Seq server isn't an option for you? That's generally the ideal approach, but understandably not always practical.

It's all hosted in Docker. But, I create my own flavor of Datalust Seq image so I could add the cert. It's a good idea -- worth a shot.

The options would be something like "Always", "When Available", and "Never" (though we could also consider explicit "On Connect"/"STARTTLS" options).
Seq already has support for this type of app setting; the main stumbling block is migrating existing instances of the app across. I might just quickly review what options we have, there, and loop back.... 🤔

Had this exact thought -- that it should be a SELECT -- but didn't see that option. Makes sense it would create backward compatibility issues. Looks like @MattMofDoom is way ahead on all of this ;)

[MattMofDoom]

I've published https://www.nuget.org/packages/Seq.App.EmailPlus-Enhanced/ to Nuget as a test package.

This has the code from my two open pull requests, which allows for testing of the enhanced code.

This includes the drop down list for TLS options - so for self signed certs it's viable to set TLS to "None" which will avoid the problem that occurs with the current default.

[mateuszligeza]

@nblumhardt @liammclennan I created simple PR #95 that is meant to fully disable the server certifiate validation.
I can't force organisation to change the way it operates and fix the reverse proxy that is messing up the mail server certificates (and preventing me from getting alerts from seq). I'm currently using the code from the above PR as a custom nuget package, but it would be nice to get this workaround added to the official repo.

[MattMofDoom]

@mateuszligeza The above will likely be rejected based on a previous PR where I attempted to add the same.

However take a look at the https://www.nuget.org/packages/Seq.App.EmailPlus-Enhanced/ which is #81 and #83 as a full package. This includes the dropdown list option to set TLS to None, which is the effect you need. These just haven't been merged yet because they're quite big enhancements, due to the nature of the features added.

For the major part, the added features are entirely optional.