Skip to content

Releases: wneessen/go-mail

v0.3.4: MessageIDs and preformatted headers

26 Oct 14:06
1ff87db
Compare
Choose a tag to compare

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

25 Oct 15:08
c321aee
Compare
Choose a tag to compare

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

  • Introducing MiddlewareType and WriteToSkipMiddleware by @wneessen in #70

Full Changelog: v0.3.2...v0.3.3

[BREAKING CHANGE] v0.3.2: New Reader type to satisfy io.Reader

20 Oct 16:48
a44383e
Compare
Choose a tag to compare

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

Full Changelog: v0.3.1...v0.3.2

v0.3.1: Access to message attachments

12 Oct 15:10
da089fc
Compare
Choose a tag to compare

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

Full Changelog: v0.3.0...v0.3.1

v0.3.0: Access to message body parts

11 Oct 17:48
94924cb
Compare
Choose a tag to compare

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 content
  • Part.GetContentType(): get the parts content type
  • Part.GetEncoding(): get the parts encoding
  • Part.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

02 Oct 11:07
15a92f1
Compare
Choose a tag to compare

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

26 Sep 08:55
664aca5
Compare
Choose a tag to compare

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

  • 3a5f639 implements the middleware concept
  • 664aca5 implements the DialAndSendWithContext() method

v0.2.7: MDNs and DSNs

12 Sep 08:06
f4cdc61
Compare
Choose a tag to compare

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 the MAIL 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 and DELAY

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 the FULL Mail From Return Option and the SUCCESS and FAILURE Recipient Notify Options
  • WithDSNMailReturnType: which enables DSNs and allows the user to specify which type of Mail From Return Option is wanted
  • WithDSNRcptNotifyType: 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

  • 5bd3cec implements the MDN support
  • f4cdc61 implements the DSN support
  • da266bc adds better test coverage

v0.2.6: fix issue with Base64 encoded mail parts

14 Aug 10:20
c6fe75f
Compare
Choose a tag to compare

#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

07 Jul 09:02
3c426ed
Compare
Choose a tag to compare

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 given embed.FS directly into the mail message
  • Msg.AttachFromEmbedFS() which will allow you to attach a file from a given embed.FS directly into the mail message

Noteworthy changes

  • #29 implements the embed.FS changes