Skip to content

v0.3.9 SMTP client port, debug logging and more

Compare
Choose a tag to compare
@wneessen wneessen released this 18 Mar 10:06
· 980 commits to main since this release
89fd5df

This release is the biggest since the initial release of the library. While there wasn't really much change on the surface, there happend a lot under the hood.

net/smtp fork

go-mail heavily relies on the Go stdlib net/smtp package. Unfortunately this lib is in feature freeze mode, so that enhancing/extending the package is not possible. This restricted us - at least to a certain degree - as we can't add features that would be useful for go-mail. For that reason we ported/forked the whole package over and adjusted all parts of go-mail to use it instead.

The original license has been imported and the license headers have been adjusted to reflect the go-mail's MIT license and the original Go BSD-3-Clause license. Additionally, the license headers have been converted to SPDX style.

Debug logging

Since we now have full control over the SMTP client part of go-mail, this allowed us to implement ldebug logging for the SMTP communication. Via the Client.WithDebugLog client option the user can enable this feature. It will then make use of the new smtp/Client.SetDebugLog method. Once the flag is set to true, the SMTP client will start logging incoming and outgoing messages to os.Stderr.

We've also implemented a simple log.Logger interface, as well as a standard logger that satisfies this interface. This allows the user to provide a custom logger, as long as the interface is stasified. If no custom logger is provided, the Stdlog will be used (which makes use of the Go stdlib again). Accordingly, a Client.WithLogger option and Client.SetLogger method have been implemented. Same applies for the smtp counterparts.

Details can be found in #102 and #115 .

More support for middlewares

With #108, #109 and #117 we provide more access to message parts (like attachments or embeds) for middlewares. Parts can now be gotten, set and deleted by middlewares.

Fix attachment reader consectuive writes

Msg.AttachReader() would not output the attached file after consecutive writes (e.g. a write to a file and then send via Client). In #111 we fixed this behaviour by first reading the io.Reader into memory and then creating a new bytes.Reader, which does support seeking. In the writeFunc we then seek to position 0 after a successful io.Copy. This is probably not the most memory efficient way of handling this, but otherwise we'll have to break the io.Reader interface, which we do not want..

To compensate this, additionally, a new way of attaching/embedding files has been added: Msg.AttachReadSeeker() and Msg.EmbedReadSeeker() which take a io.ReadSeekeras argument instead. These two methods will skip the reading into memory and make use of the Seek method of the corresponding interface instead.

We recommend to make use of the new methods instead, to make the memory footprint low.

Special thanks

Special thanks go to @Karitham, @cvette and @halilylm for reporting bugs and/or providing PRs to address issues. Also big thanks to @james-d-elliott of the Authelia project for providing helpful insights on various issues with the library.

What's Changed

New Contributors

Full Changelog: v0.3.8...v0.3.9