Releases: wneessen/go-mail
v0.3.4: MessageIDs and preformatted headers
This release introduces a bugfix and an enhancement:
- A bug was fixed in the MessageID generation. Due to the lack of randomness, the generated IDs for several messages might be the same. Therefore the requirement of uniqueness is not fulfilled. This has been fixed via #75
- A new methods
SetHeaderPreformatted
has been introduced, which allows the user to set a message header with preformated text. The header will not be altered during the mail message processing/output. More details in #77
What's Changed
- Fixed SetMessageID message ID generation by @wneessen in #75
- Add SetHeaderPreformatted() method by @wneessen in #77
- The new messageID generated with #74 is a bit too long by default. Th… by @wneessen in #78
Full Changelog: v0.3.3...v0.3.4
[BREAKING CHANGE] v0.3.3: MiddlewareType and WriteToSkipMiddleware
This release will break current Middleware implementations
For middlewares to be able to access the fully written mail message, we need a way to execute WriteTo
without the calling middleware to be handled, otherwise we end up in an infinite loop.
This release introduces the MiddlewareType
and the corresponding change of the Middleware
interface. We now require to return the MiddlewareType
when the Type()
method on the interface is called. Conveniently MiddlewareType
is an alias to a string
.
This way we can also introduce the WriteToSkipMiddleware()
method which takes a MiddlewareType
as argument. This will allow us to use a WriteTo
call with the initiating Middleware
itself to be skipped.
Please note: This release will break any existing go-mail Middleware
, since they don't provide a Type()
method yet.
What's Changed
Full Changelog: v0.3.2...v0.3.3
[BREAKING CHANGE] v0.3.2: New Reader type to satisfy io.Reader
Initially the Msg
implemented a io.Reader
interface by providing a Read
methods. Unfortunately the method chosen for this method was very naive. It works fine for smaller messages but could result in wrong data returned for larger messages or i. e. used in a bufio.Reader
with non consecutive reads. Since we did not track the position and state of the reading operation, duplicate data might be returned to the caller eventually even leading into infinite loops.
This release fixes the issue be introducing a new Reader
type. The Reader
type satisfies the io.Reader
interface and returns the data properly as well as returns EOF
in case the end of data is reached.
The initial Read()
method has been removed from the Msg
type and instead a NewReader()
method has been introduced that returns the Reader
type.
BREAKING CHANGE: Since we remove the Read
method from the Msg
the Msg
does not satisfy the io.Reader
interface anymore, which is considered a breaking change. But given that the returned data of the original implementation might return duplicate or wrong data, this breaking change is considered as the right decision.
What's Changed
- Introduce golangci-lint by @wneessen in #66
- Fix codecov Go version setup by @wneessen in #67
- New Reader type by @wneessen in #68
Full Changelog: v0.3.1...v0.3.2
v0.3.1: Access to message attachments
This release introduces a couple of new methods on the Msg
, which will help the Msg.Middleware
to deal with Msg
attachments.
To get the Msg
attachments, we can now use the Msg.GetAttachments()
methods to get the list of currently assigned attachments to the Msg.
To set the Msg
attachments, we can now use the Msg.SetAttachments()
methods to set a list of *File
as Msg
attachments.
What's Changed
- Expose Msg attachments fields by @dhia-gharsallaoui in #63 (Thanks to Dhia Gharsallaoui for the PR!)
Full Changelog: v0.3.0...v0.3.1
v0.3.0: Access to message body parts
This release introduces a couple of new methods on the Msg
as well as the Part
. This will help the Msg.Middleware
to be more extensible since we allow access not only to headers but also to body parts.
To get the Msg body parts, one can now utilize the Msg.GetParts()
methods to get the list of currently assigned message parts to the Msg
.
Each Part
has now an additional list of getters/setters, to read and modify the given part:
Part.GetContent()
: get the parts contentPart.GetContentType()
: get the parts content typePart.GetEncoding()
: get the parts encodingPart.GetWriteFunc()
: get the parts write function
Each of these Part.Get*()
methods also has an corresponding Part.Set*()
methods what overrides the current value
Noteworthy changes
- a3a2b0e Introduces the new getter/setter methods
v0.2.9: Middleware collection
This release is a very minor release. It only adds Msg.GetGenHeader()
so that 3rd party middleware can access already set generic headers, in case they want to alter them.
This release is important though, since it adds information about a new Middlware repository we started: https://github.com/wneessen/go-mail-middleware. A collection of useful middlewares that can be used with go-mail. A specific section has been added to the README.
Noteworthy changes
- 10575c0: adds the
Msg.GetGenHeader()
method
v0.2.8: Middleware and DialAndSendWithContext
This release adds a middleware concept to the Msg
context to allow 3rd parties to extend mail messages with their own code. Thanks to Dhia Gharsallaoui for the PR!
It was also pointed out on Discord that it would be useful to have a DialAndSendWithContext()
method, which is also part of this release.
Noteworthy changes
v0.2.7: MDNs and DSNs
This release adds support for requesting MDNs (RFC 8098) and DSNs (RFC 1891) to be delivered for outgoing mail messages. We've also added more test coverage.
MDNs
MDNs (Message Disposition Notification) allows you to request a - what is often referred to as - "read receipt". This is implemented via a message header and it's up the the recipients MUA to send out this notification to the sender.
Code example:
func main() {
// [...]
m := mail.NewMsg()
if err := m.FromFormat("Max Tester", "[email protected]"); err != nil {
panic(err)
}
if err := m.To("[email protected]"); err != nil {
panic(err)
}
m.Subject("This is an example")
if err := m.RequestMDNTo("[email protected]"); err != nil {
fmt.Printf("failed to set MDN request header: %s", err)
}
// [...]
}
For MDNs we implement the same methods as for the To
methods:
RequestMDNTo
RequestMDNToFormat
RequestMDNAddTo
RequestMDNAddToFormat
DSNs
DSNs (Delivery Status Notification) are an extension to the SMTP protocol and need to be supported by the sending server. The RFC for DSNs defines different parameters of which we've implemented the once which we think make most sense for go-mail:
- The
RET
extension for theMAIL FROM
command, to let the user specify if a DSN should contain the full mail (FULL
) or only headers (HDRS
) of the sent mail. - The
NOTIFY
extension that allows the user to request a DSN for the different types of allowed situations:NEVER
,SUCCESS
,FAILURE
andDELAY
ENVID
and ORCPT
are currently not supported but might follow in a later relaese (please open an issue if you see usefulness in this).
Since DSNs are part of the SMTP protocol, these need to be enabled on the Client
. We've added 3 ways to do so:
WithDSN
: Which enables DSNs, sets theFULL
Mail From Return Option and theSUCCESS
andFAILURE
Recipient Notify OptionsWithDSNMailReturnType
: which enables DSNs and allows the user to specify which type of Mail From Return Option is wantedWithDSNRcptNotifyType
: which enables DSNs and allows the user to specify which types of Recipient Notify Options are wanted
Code example:
func main() {
// [...]
cl, err := mail.NewClient("relay.example.net",
mail.WithDSNMailReturnType(mail.DSNMailReturnFull),
mail.WithDSNRcptNotifyType(mail.DSNRcptNotifyFailure, mail.DSNRcptNotifyDelay, mail.DSNRcptNotifySuccess))
if err != nil {
fmt.Printf("failed to create new client: %s\n", err)
os.Exit(1)
}
// [...]
}
Noteworthy changes
v0.2.6: fix issue with Base64 encoded mail parts
#37 brought up an issue, in which some mail servers would not accept mails sent via go-mail services. They returned 550 Maximum line length exceeded (see RFC 5322 2.1.1)
errors. It turns out, that Go's encoding/base64 does not add line breaks when encoding data. This release adds a Base64LineBreaker
struct, which satisfies the io.WriteCloser interface and makes sure that mail parts, that are base64 encoded, are properly broken up at 76 chars.
Noteworthy changes
- c6fe75f introduces the
Base64LineBreaker
Thanks to @chriselkins for bringing this to my attention!
v0.2.5: embed.FS support
This release adds support for embedding/attaching files directly from embed.FS
. We've added two new methods:
Msg.EmbedFromEmbedFS()
which will allow you to embed a file from a givenembed.FS
directly into the mail messageMsg.AttachFromEmbedFS()
which will allow you to attach a file from a givenembed.FS
directly into the mail message
Noteworthy changes
- #29 implements the embed.FS changes