The commit introduces improved variable names in the SMTP client code that are more expressive and better describe the function they perform. This is combined with corrections to some code comments. It's aimed to increase code readability and maintainability. Updates are made across the client_119.go and client.go files to ensure consistent naming conventions.
Introduced the SMTPAuthNoAuth mechanism in the auth.go file meant for instances where authentication is not required or supported. Adjusted tests in client_test.go to account for this new mechanism. Minor order modifications were also made to the list of supported SMTP AUTH types and respective tests for better consistency.
Closes#176
Test cases have been added for numerous client functionalities including WithTLSPortPolicy option for the NewClient method, Client.SetSSLPort method, and the Client.DialWithContext method with the fallback port functionality. Minor code simplification has also been performed in the 'SetSSLPort' function in client.go file.
Enhanced the unit tests in client_test.go by adding more test cases for SSL Port and TLS Port Policy. These additions contribute to more effective coverage of edge cases and increase the robustness of the test suite.
This commit adds checks in the testing functions to verify the successful implementation of message delivery status. A new attribute `isDelivered` is now being validated in our tests, reinforcing the message tracking system and enhancing the overall reliability of our application.
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 refactors the the DSN (RFC 1891) SMTP client handling, that was introduced in f4cdc61dd0.
While most of the Client options stay the same, the whole workaround logic for the SMTP client has been removed and added as part of the SMTP client instead.
This was we got rid of the Client's own `mail()`, `rcpt()`, `dsnRcpt()`, `dsnMail()` methods as well as the copies of the `cmd()` and `validateLine()` methods. The Client is now using the proper `Mail()` and `Rcpt()` methods of the SMTP client instead.
Resolves#101.
Since we now have full control over the SMTP client we can also access the message input and output.
This PR introduces a new debug logging feature. Via the `Client.WithDebugLog` the user can enable this feature. It will then make use of the new `smtp/Client.SetDebugLog` method. Once the flag is set to true, the SMTP client will start logging incoming and outgoing messages to os.Stderr.
Log directions will be output accordingly
As part of #97 we are going to fork the official `net/smtp` package into go-mail to provide us with more flexibility.
This commit fulfills the first big step of importing the package into smtp/. Also go-mail's own LoginAuth has been moved from auth/ into smtp/ to be consistent with the stdlib.
There are still a couple of open issues (i. e. license adjustments and making golangci-lint happy) but so far all tests already work, which is a good start.
This fixes#94 and basically reverts d0f0435. As James points out correctly in #94, we should not assume specific responses from the server. As long as the spec is followed and the server returns the correct SMTP code, we should not do our own magic.
I've also extended the `getTestConnection` method in client_test.go, so that we can specify more test environment options like `TEST_PORT` and `TEST_TLS_SKIP_VERIFY`. This was needed for testing with the ProtonMail Bridge which listens on a different port and has non-trusted certificates.
As proposed by @iwittkau the `SendError` type now has a `IsTemp()` method as well indicating to the user if the delivery error is retryable or not.
Since we want to use it in the error response from the Client functions like `Send` or `DialAndSend` we need to return the SendError type not only as part of the `*Msg` but also as return value for these methods. Hence, the changes made for #85 been overhauled to return the new error type instead. In the pre Go1.20 version of the `Send()` method we need to return an accumulated version of the SendError type, since we don't have `errors.Join()` and therefore, if more than one error occurred during the delivery we return an ambiguous error reason since we can't tell which of the captured errors is main error. For more details the user can always check the `*Msg.SendError`
Did a complete overhaul of the senderror.go.
- the list of `errors.New()` has been replaced with constant itoa error reasons as `SendErrReason`. Instead, the `Error()` method now reports the corresponding error message based on the reason.
- The `SendError` received a `Is()` method so that we can use `errors.Is()` for very specific error checking. I.e. we can check for `&SendErrors{Reason: ErrSMTPMailFrom, isTemp: true}`. This provides much more flexibility in the error checking capabilities
- A `isTemp` field has been added to the `SendError` type, indicating whether the received error is temporary and can be retried or not. Accordingly, the `*Msg` now has a `SendErrorIsTemp()` method indicating the same. The decision is based on the first 3 characters returned from the SMTP server. If the error code is within the 4xx range, the error is seen as temporary
- A test for the SendError type has been added
This PR introduces the `SendError` type which implements the error interface.
A new `senderror` field has been added to the `Msg` as well, so introduce this type to it.
I've also added different error variables that indicate the different things that can go wrong during mail delivery. These variables can be checked for, for each `Msg` using the `errors.As` method
The `Error()` method of `SendError` will return a detailed error string on why the `Msg` could not be delivered.
Additionally, `HasSendError()` and `SendError()` methods have been added to `Msg`. While `HasSendError()` simply returns a bool in case a `Msg` failed during delivery, the `SendError()` will return the full `SendError` error interface.
This allows disabling the Noop command during the dial. This is useful for servers which delay potentially unwanted clients when they perform commands other than AUTH.
`Client.Send()` provides the possibility to send multiple `*Msg` in one go. If one of the `*Msg` caused an error with the sending mail server, we were returning completely, while not processing any `*Msg` that came after the failing message.
This PR fixes this behaviour by processing each message first and then return a accumulated error in case any of the `*Msg` processing failed
Additionally, this PR separates the `Client.Send()` method into two different versions. One that makes use of the new `errors.Join()` functionality that is introduced with Go 1.20 and one that handles it the old way for any supported version lower than Go 1.20
# SUMMARY
* Bad licenses:
* Deprecated licenses:
* Licenses without file extension:
* Missing licenses:
* Unused licenses:
* Used licenses: CC0-1.0, MIT
* Read errors: 0
* Files with copyright information: 45 / 45
* Files with license information: 45 / 45
Congratulations! Your project is compliant with version 3.0 of the REUSE Specification :-)