Bump github.com/wneessen/go-mail from 0.4.4 to 0.5.0

[dependabot]

Bumps github.com/wneessen/go-mail from 0.4.4 to 0.5.0.

Release notes

Sourced from github.com/wneessen/go-mail's releases.

v0.5.0: Concurrency-safety, SCRAM-SHA, improved error handling and better GoDoc documentation // POTENTIALLY BREAKING

Welcome to go-mail v0.5.0! This release is a big one, bringing new features and improvements to the go-mail codebase!

Goroutine-/thread-safety (Potentially breaking)

With #307 we've made go-mail goroutine-safe by introducing a sync.Mutex. Concurrency-safety was a much requested feature, now allowing you to dial your Client and then use that Client in different goroutines. While we've added a lot of new tests (including a test SMTP server to which we connect to in different goroutines), this feature has not been extensively tested in an production environment. Therefore we've marked this features (and respectively this release) as a potentially breaking release. If you plan to use go-mail in a concurrency scenario, please test properly and report back any issues.

SCRAM-SHA-1(-PLUS) / SCRAM-SHA-256(-PLUS) SMTP authentication support

With #310 we have introduced SMTP authentication functions for SCRAM-SHA-1(-PLUS) and SCRAM-SHA-256(-PLUS). Most of the ground work was contributed by @​drakkan. @​wneessen cleaned up the code a bit, added channel bindings support and added several test cases.

SCRAM-SHA-X(-PLUS) isn't commonly supported, yet but I've tested the code with Dovecot (no channel binding support) and mox (supports both) and the code seems to be working properly. Feedback from using SCRAM with other systems is appreciated!

Thanks again to @​drakkan for the excellent WIP code.

Improved error handling

With #301 the error handling was refactored in accordance to #168. Errors are not nested into each other anymore. The send logic for a single message has been moved to the non-version-specific Client.go while the version-specific only handle multi-message handling and error combination. Error messages now also refer to a message ID of the message that failed (if present), for easier debugging.

Thanks to @​mitar for pointing out the flaws in the old error handling system and for suggesting the improvements.

Enhanced SMTP LOGIN authentication handling

With #312 we've refactored the SMTP LOGIN auth handling, to improve compatibility with various server responses.

In detail: before, we were only roughly following the Microsoft Spec they defined for MS Outlook. Meaning:

• Sending AUTH LOGIN (server might responds with "Username:")
• Sending the username (server might responds with "Password:")
• Sending the password (server authenticates)

This is the common approach for most mail systems/providers and is the specified way by Microsoft in their MS-XLOGIN spec.

Yet, there is also an old IETF draft for SMTP AUTH LOGIN that states for clients:

The contents of both challenges SHOULD be ignored.

Since there is no official standard RFC and we've seen different implementations of this mechanism (sending "Username:", "Username", "username", "User name", etc.) we now follow the IETF-Draft instead and ignore any server challange to allow compatiblity with most mail servers/providers. This way it works with servers that follow the Microsoft way but also any other kind of implementation (like i. e. Mox).

Improved GoDoc documentation

With #324 we revises the GoDoc documenation comments for the whole package. It provides much more details for each method in a more standardised format, allowing users of the package to get better information on what does what. This is especially helpful for LSP implementations like gopls.

Simplified random number generation

The random methods for generating random numbers have been simplified and the use of crypto/rand has been replaced by math/rand or math/rand/v2 (depending on the used Go version). We've realized that for our use cases, math/rand will provide enough randomness. It simplies the randNum code a lot.

Dependencies (Potentially breaking)

So far, we were always commited to keep go-mail dependency-free, meaning only relying on the Go Stdlib. So far this has been working well and we believe that people appreciate that no further dependcies are added to their project, when they import go-mail. Yet, we've finally reached a point, where adding new features might require us to import some limited dependencies. This happened with the SCRAM support in #310. We've done a poll beforehand to see if the community is fine with this and the common agreement is, that people are ok with a limited, well curated list of external packages as long as the packages are still maintained and have a good security reputation. Therefore this release adds the first dependencies to go-mail - both from the Go extended library:

• golang.org/x/crypto
• golang.org/x/text

As your codebase might not allow for additional dependencies, this feature is also marked as Potentially breaking

We hope you like this release and a big thanks goes out the community that contributed to this release.

... (truncated)

Commits

• a94e721 Update doc.go
• 46ca42e Merge pull request #324 from wneessen/better-godoc
• f0388ec Refactor TLSPolicy documentation and String method
• 6ce5c2a Enhance documentation for SendError methods and fields
• 5d79ff6 Enhance and clarify Reader struct documentation
• cd90c3d Update randNum function and documentation for multiple versions
• e640f2d Add detailed comments and return descriptions to Part methods
• 295155b Refactor and document msgWriter methods
• 0b10504 Refine WriteToTempFile docstring
• 3333c78 Refactor documentation for Importance methods
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)