In the updated version of msgwriter.go, an additional error handling process has been included. If an error is detected when creating a new part in the message writer, this error is stored and prevents executing the writeBody function. This fixes nil pointer dereference in `mw.writeBody` if an error occured previously.
A `const CallDepth` placeholder has been introduced and has been set to 2. This is used as an argument in Output method calls in various log levels like debug, info, warn, and error in place of previously hardcoded '2'. This change improves the readability of the code. The '2' represented the call depth of log.Logger's Output method, which wasn't immediately clear with the hardcoded value.
- Bump version in doc.go
- Add sonarlint to .gitignore
- Update README to reflect the changes and contributors
- Fixed typos in auth_cram_md5_118.go, msg.go, msg_test.go, reader.go and smtp_ehlo_117.go
Fixes#121. `defer` in for loops can possibly lead to leaks.
The whole handling including the defer are now moved into anonymous functions outside the for loop and are called form the loop instead. This way the defer is handle when the inline function finishes
Since we are Go <1.20 compatible, we can't easily combine errors here. The suggested golangci-lint fix will not work neither, since the %w verb can't be used twice. Therefore, for now we will ignore the linting error
Closes#119
As stated in https://github.com/wneessen/go-mail/pull/102#issuecomment-1411956040 it would be beneficial if, instead of forcing the Go stdlib logger on the user to provide a simple interface and use that for logging purposes.
This PR implements this simple log.Logger interface as well as a standard logger that satisfies this interface. If no custom logger is provided, the Stdlog will be used (which makes use of the Go stdlib again).
Accordingly, a `Client.WithLogger` and `Client.SetLogger` have been implemented. Same applies for the smtp counterparts.
This PR addresses #110.
`Msg.AttachReader()` would not output the attached file after consecutive writes (e.g. a write to a file and then send via Client).
This PR fixes this behaviour by first reading the io.Reader into memory and then creating a new `bytes.Reader`, which does support seeking. In the writeFunc we then seek to position 0 after a successful `io.Copy`. This is probably not the most memory efficient way of handling this, but otherwise we'll have to break the `io.Reader` interface.
Additionally, a new way of attaching/embedding files has been added: `Msg.AttachReadSeeker()` and `Msg.EmbedReadSeeker()` which take a ´io.ReadSeeker` as argument instead. These two methods will skip the reading into memory and make use of the `Seek` method of the corresponding interface instead.