Skip to content

v0.5.1: SMTP auth fixes and logging optimizations
Compare
Choose a tag to compare
@wneessen wneessen released this 16 Oct 08:25
· 392 commits to main since this release
v0.5.1
8ea80c0
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

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 Client would 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 SMTPAuthNoAuth from an empty string to "NOAUTH". This value is set as default for the Client in NewClient. This way we always have a fixed assignment and an empty string would not skip authentication. The auth() method has been updated to either assign the smtp.Auth function if SMTPAuthType is not set to "NOAUTH" or skip the part there is already an auth function set (this would only happen when SetSMTPAuthCustom or WithSMTPAuthCustom were used).

If SMTPAuthType is 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() and SetLogAuthData(bool). With either of these you can instruct the Client to 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

  • Simplify message id generation and get rid of randnum by @wneessen in #329
  • Redact logging of SMTP authentication data by @wneessen in #338
  • Add default SMTP authentication type to NewClient by @wneessen in #335
  • code duplication reduction for jsonlog.go and stdlog.go by @sarff in #336

CI/CD maintenance changes

New Contributors

  • @sarff made their first contribution in #336. Thank you very much!

Full Changelog: v0.5.0...v0.5.1

Contributors

ugexe, wneessen, and 4 other contributors
Assets 2
Loading