v0.3.9 SMTP client port, debug logging and more #123
Closed
wneessen
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 newsmtp/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, theStdlog
will be used (which makes use of the Go stdlib again). Accordingly, aClient.WithLogger
option andClient.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 newbytes.Reader
, which does support seeking. In thewriteFunc
we then seek to position 0 after a successfulio.Copy
. This is probably not the most memory efficient way of handling this, but otherwise we'll have to break theio.Reader
interface, which we do not want..To compensate this, additionally, a new way of attaching/embedding files has been added:
Msg.AttachReadSeeker()
andMsg.EmbedReadSeeker()
which take aio.ReadSeeker
as argument instead. These two methods will skip the reading into memory and make use of theSeek
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
This discussion was created from the release v0.3.9 SMTP client port, debug logging and more.
Beta Was this translation helpful? Give feedback.
All reactions