v0.4.1: Better logging, attachment removing, login darft and more *POTENTIALLY BREAKING* #175
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 of go-mail brings some new features as well as some code clean up and stability improvments.
Improved logging interface (Potentially Breaking Change)
The debug logging system in go-mail has been refactored. A new custom log type
Log
was introduced, that includes the message direction, format and arguments. TheLogger
interface and theStdlog
implementation were modified to accept this new type. This change is breaking custom implementations of theLogger
interface, but the new interface provides much more flexibility (#136/#141). Additionally we added support for JSON logging (#142) using thelog/slog
package that has been added to the stdlib in Go 1.21.This change is breaking custom logger implementations
Removal of attachments/embeds
#147 adds support for removing all attachments/embeds/parts from a
Msg
. This allows to re-use aMsg
and allows for replacing message parts.The following methods can be used:
Msg.UnsetAllAttachments()
Msg.UnsetAllEmbeds()
Msg.UnsetAllParts()
Thanks to @leahoop for their first PR!
Reading of multiple addresses from a single comma-separated string
#155/#152 add support for three new methods that allow to read multiple recipient addresses for the
TO:
,CC:
andBCC:
fields from a single comma-separated string.The following methods have been added:
Msg.ToFromString(string)
Msg.CcFromString(string)
Msg.BccFromString(string)
Thanks to @suntong for requesting this useful feature!
Delivery status indication for messages
With #167 we added support for delivery status indication of messages. This is especially helpful for bulk mailings to identify if a message was actually delivered or not. A helper method
IsDelivered
has been added that will returntrue
after successful delivery of aMsg
. Thanks to @mitar for requesting this useful feature!Making use of best practice default ports and fallback ports
When using SSL or STARTTLS, so far the default port was always 25, which is against best practices as described in RFC8314, section 3.3. With #170 we've deprecated the
WithSSL()
andWithTLSPolicy
options in favour ofWithSSLPort(bool)
andWithTLSPortPolicy(TLSPolicy)
.WithSSLPort
tells theClient
to use a SSL/TLS connection and automatically sets the port to 465.WithTLSPortPolicy
tells the client to use the provided TLSPolicy and sets the correct port automatically. Port 587 is used forTLSMandatory
andTLSOpportunistic
.NoTLS
will allways use port 25. If the connection fails withTLSOpportunistic
, a plaintext connection is attempted on port 25 as a fallback.Thanks to @muhlemmer for raising the request and providing the first part of the PR.
Code cleanup and stability
The codebase has been reviewed and a couple of potential nil pointer dereferences have been identified and fixed.
Additionally, a potential panic has been fixed in
fileFromReader
(#161) - thanks to @rami-dabain for their first PR!What's Changed
fileFromReader
by @rami-dabain in Added return error tofileFromReader
#161New Contributors
fileFromReader
#161Full Changelog: v0.4.0...v0.4.1
This discussion was created from the release v0.4.1: Better logging, attachment removing, login darft and more *POTENTIALLY BREAKING*.
Beta Was this translation helpful? Give feedback.
All reactions