deps(api): update module github.com/wneessen/go-mail to v0.5.2 #2044
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2044 +/- ##
===========================================
- Coverage 51.36% 30.87% -20.50%
===========================================
Files 400 180 -220
Lines 21618 2951 -18667
Branches 551 551
===========================================
- Hits 11105 911 -10194
+ Misses 9880 1990 -7890
+ Partials 633 50 -583 ☔ View full report in Codecov by Sentry. |
renovate
bot
force-pushed
the
renovate/github.com-wneessen-go-mail-0.x
branch
from
c2cdc2c
to
2e87fc5
Compare
renovate
bot
force-pushed
the
renovate/github.com-wneessen-go-mail-0.x
branch
from
2e87fc5
to
e02fb06
Compare
renovate
bot
changed the title
renovate
bot
force-pushed
the
renovate/github.com-wneessen-go-mail-0.x
branch
from
e02fb06
to
9986866
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.4.4->v0.5.2Release Notes
wneessen/go-mail (github.com/wneessen/go-mail)
v0.5.2: : Better tests, minor bug fixes, unencrypted auth methods and fig-support.Compare Source
Welcome to go-mail v0.5.2! This release is mainly a maintenance release.
fig.StringUnmarshaler support for SMTPAuthType
With #341 we introduce support for the
fig.StringUnmarshalerinterface forSMTPAuthType. This allows users of fig to reference themail.SMTPAuthTypedirectly in their fig config.Allow unencrypted PLAIN and LOGIN smtp authentication
The PR #344 introduced two new
SMTPAuthTypetypes:SMTPAuthPlainNoEncandSMTPAuthLoginNoEnc. Both allow PLAIN and LOGIN authentication over unencrypted connections. This can be useful if the connection has already been secured in a different way (e. g. a SSH tunnel).Overhaul of the test suite and GH workflow
The PRs #348, #349 and #352 are a full overhaul of the go-mail test suite. Almost all tests have been rewritten to better coverage, visibility and maintainability. We've now covered +92% of all code. The Github workflow was also improved and is now less error prone.
During the tests rewrite a couple of minor bugs were found and fixed on the way:
What's Changed
CI/CD maintenance changes
dc2f7b0to8406f4fby @dependabot in https://github.com/wneessen/go-mail/pull/351New Contributors
Full Changelog: wneessen/go-mail@v0.5.1...v0.5.2
v0.5.1: : SMTP auth fixes and logging optimizationsCompare Source
Welcome to go-mail v0.5.1! This release brings a bug fix and some optimizations around logging.
Regression fix for SMTP authentication
With v0.5.0 we unintentionally introduced a regression for the SMTP authentication part of go-mail - at least for some edge cases. As reported in #332, in case the user did not provide an explicit SMTP authentication option, the
Clientwould fail with an "server does not support SMTP AUTH" error. The quick work-around was setting SMTP Auth to "Custom" as pointed out in #328. While it improved the security of the package, as it would not skip authentication if none was given, it was breaking in some edge cases and the "Custom" auth type was not meant to be the default.We now changed the
SMTPAuthNoAuthfrom an empty string to "NOAUTH". This value is set as default for theClientinNewClient. This way we always have a fixed assignment and an empty string would not skip authentication. Theauth()method has been updated to either assign thesmtp.Authfunction ifSMTPAuthTypeis not set to "NOAUTH" or skip the part there is already an auth function set (this would only happen whenSetSMTPAuthCustomorWithSMTPAuthCustomwere used).If
SMTPAuthTypeis set to an empty string, the authentication assignment would fail as it is a not supported mechanism, therefore making sure that the client wouldn't accidentaly skip the authentication at all.We are sorry if this broke your code with the v0.5.0 release. Thanks to @james-d-elliott and @ugexe for reporting this and for testing the fix.
SMTP authentication data logging
go-mail claims to ship with sane defaults. While this is true, there was one aspect where this wasn't true: debug logging. The debug logger would potentially expose SMTP authentication data to the logs, which could pose a risk. With v0.5.1 we now redact SMTP authentication data by default as a sane and secure default. We realize though, that you sometimes need access to the authentication data. Therefore two new options were introduced to the
Client:WithLogAuthData()andSetLogAuthData(bool). With either of these you can instruct theClientto log full SMTP authentication data again.Simplification of the message ID generation
As pointed out by @mitar in #326, the way we generated the message ID was much to complicated using different sources of randomness while already using a secure string generator. #329 simplied the message ID generation to only use the secure string generator and get rid of the rest of the strings and numbers we added to the message ID. We now have 64 possible characters to generate a 22 character long string, which provides approx. 132 bits of entropy. This should more than enough to guarantee a unique ID for each message.
What's Changed
CI/CD maintenance changes
New Contributors
Full Changelog: wneessen/go-mail@v0.5.0...v0.5.1
v0.5.0: : Concurrency-safety, SCRAM-SHA, improved error handling and better GoDoc documentation // POTENTIALLY BREAKINGCompare Source
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 yourClientand then use thatClientin 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:
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:
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/randhas been replaced bymath/randormath/rand/v2(depending on the used Go version). We've realized that for our use cases,math/randwill provide enough randomness. It simplies therandNumcode 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/cryptogolang.org/x/textAs 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.
What's Changed
CI/CD maintenance changes
0c0f395tof885e52by @dependabot in https://github.com/wneessen/go-mail/pull/304f885e52to884b794by @dependabot in https://github.com/wneessen/go-mail/pull/305Full Changelog: wneessen/go-mail@v0.4.4...v0.5.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.