v0.3.7: Improved delivery error handling

This release introduces the SendError type which satisfies the error interface and provides a better way to identify delivery errors. A new sendError field has been added to the Msg as well, to also allow per-message error handling in bulk mailings.

We've also added different SendErrReason that indicate the different things that can go wrong during mail delivery. These reasons can be checked for, for each Msg using the errors.Is methods. Alternatively, the errors.As method can be used to unwrap the SendError to get access to it's methods. The SendError provides a IsTemp method that returns true if the delivery error is of temporary nature.

This is useful for delivery retries. For example the following code could be used to decide whether the error is retryable or not:

	if err := c.DialAndSend(m); err != nil {
		var se *mail.SendError
		if errors.As(err, &se) && se.IsTemp() {
			// retryable error
			log.Printf("temporary error, will re-try")

			/*
			  perform some re-try logic here
			*/
		}
		// permanent error
		log.Fatal(err)
	}

If the Send method runs into more than one error during delivery, these errors are accumulated and returned with the reason ErrAmbiguous, since it's not possible to exactly say what caused the error. For this it comes handy, that the *Msg now provides per-message send errors. The *Msg now has HasSendError(), SendErrorIsTemp() and SendError(). While HasSendError() simply returns a bool in case a *Msg failed during delivery and SendErrorIsTemp() returns true if it's a temporary error, the SendError() will return the full SendError error of the corresponding *Msg.

The Error() method of SendError will return a detailed error string based on the accumulated errors that were collected during the delivery.

Thanks to @imirkin and @iwittkau for providing valueable feedback and performing code review on the PR.

What's Changed

• Introduction of new error type for sending errors by @wneessen in #91

Full Changelog: v0.3.6...v0.3.7