Commit graph

486 commits

Author SHA1 Message Date
1e959a591d
Update doc.go
Bump version to 0.3.8
2023-01-07 11:58:11 +01:00
fb1d3197c8
Merge pull request #95 from wneessen/94-login-auth-next-handler-should-unconditionally-succeed-if-more-is-false
Fix SMTP AUTH LOGIN method for servers with uncommon success messages
2023-01-07 11:57:46 +01:00
39a9949e78
Fix auth_test.go accordingly
Removed "2.7.0 Authentication successful" challenge since this should never be sent with `more == true`.
2023-01-07 11:48:59 +01:00
862749f863
Fix SMTP AUTH LOGIN method for servers with uncommon success messages
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.
2023-01-07 11:31:46 +01:00
3b3c1e6e8d
Merge pull request #91 from wneessen/feature/90_provide-a-way-of-knowing-which-emails-failedsucceeded-in-sending
Introduction of new error type for sending errors
2023-01-03 11:22:32 +01:00
3d0939b597
Bump version to 0.3.7 for new release 2023-01-03 11:19:07 +01:00
5897bddd11
Update msg.go
Co-authored-by: iwittkau <iwittkau@users.noreply.github.com>
2023-01-02 22:29:10 +01:00
dbb596893d
Update msg.go
Co-authored-by: iwittkau <iwittkau@users.noreply.github.com>
2023-01-02 22:28:39 +01:00
b12b0bb363
Update client_test.go
Co-authored-by: iwittkau <iwittkau@users.noreply.github.com>
2023-01-02 22:22:31 +01:00
e6b73c2397
Update client_119.go
Co-authored-by: iwittkau <iwittkau@users.noreply.github.com>
2023-01-02 22:21:23 +01:00
8d86c3d8b2
Better test coverage for senderror.go 2023-01-02 21:55:37 +01:00
b8ee25f014
Simplify error return to make golangci-lint happy 2023-01-02 20:49:35 +01:00
8463f8524a
Fix merge conflict 2023-01-02 12:16:47 +01:00
b8af7a6ffc
Merge remote-tracking branch 'origin/feature/90_provide-a-way-of-knowing-which-emails-failedsucceeded-in-sending' into feature/90_provide-a-way-of-knowing-which-emails-failedsucceeded-in-sending
# Conflicts:
#	senderror.go
2023-01-02 12:15:39 +01:00
2c7ea3e532
More changes in regard to #90
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`
2023-01-02 12:14:14 +01:00
15b3a0028a
Fix/optimize isTempError method
Not that this particular part of the code is performance critical, but I figured that the `strconv.Atoi()` is actually useless in here.

Since all we want to know is if the error code from the SMTP server is a 4xx error, we can just check the first rune of the returned error. The `Atoi` provides us with no advantage over the simple rune compare (except of taking about 3ns longer to execute)
2023-01-01 20:35:21 +01:00
43efd6b3a8
Add missing REUSE header in senderror_test.go 2023-01-01 14:25:44 +01:00
f6709e90cd
Make golangci-lint happy by using errors.As instead of using type assertion on error (which can fail on wrapped errors) 2023-01-01 14:25:00 +01:00
78df991399
Proposal change for #90
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
2023-01-01 14:20:13 +01:00
42a1fde51f
Fix missing REUSE license header in senderror.go 2022-12-31 12:47:20 +01:00
88eb4c5663
I think it's fair that we reset the Msg.senderror to nil before we Client.Send it.
Since the send error indicate an error during the mail delivery, in my opinion it should be reset when a re-send is initiated, so that the senderror field always represents the latest delivery error. The send error should be checked after mail delivery and before a retry is started.
2022-12-31 12:46:11 +01:00
47bff15de9
Introduction of a Msg error type as proposal for #90
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.
2022-12-31 12:40:42 +01:00
f454ae8c41
Merge pull request #88 from james-d-elliott/feat-without-noop
feat: without noop option
2022-12-26 16:49:38 +01:00
e7b162a295
Merge pull request #87 from james-d-elliott/fix-tls-config
fix: tls config unused with dialer
2022-12-26 16:47:15 +01:00
James Elliott
567276d75d
feat: without noop option
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.
2022-12-27 00:06:20 +11:00
James Elliott
b8646489ae
fix: tls config unused with dialer
This ensures the configured tls.Config is used with the tls.Dialer.
2022-12-26 23:48:52 +11:00
6a7d49f1b6
Update doc.go
Bump version to 0.3.6 as preparation for the next release
2022-12-10 13:53:07 +01:00
c571650c97
Merge pull request #86 from wneessen/fix/85_clientsend-returns-is-one-of-the-given-messages-fails
Fix #85: Client.Send() failing for all messages if one is broken
2022-12-10 13:51:35 +01:00
48b4dc6b6c
Fix #85: Client.Send() failing for all messages if one is broken
`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
2022-12-10 13:41:00 +01:00
32ac691112
Update doc.go
Bump Version to 0.3.5
2022-11-19 11:33:06 +01:00
2a228c5b08
Merge pull request #83 from wneessen/feature/80_add-getaddrheader
#80: GetAddrHeader and SetGenHeader
2022-11-19 11:31:28 +01:00
17b9d2ccf6
#80: GetAddrHeader and SetGenHeader
This PR introduces two major changes:

* SetHeader and SetHeaderPreformatted have been deprecated in favour of SetGenHeader and SetGenHeaderPreformatted
  As pointed out in #80 the naming was pretty confusing, given that we already have SetAddrHeader. With the new naming convention it should be more clear. For compatibility reasons the old methods have been kept for now but in reality they are just aliases to the new methods
* GetAddrHeader and GetAddrHeaderString have been introduced
  As requested in #80 analogous to GetGenHeader we also need a similar method for the address headers. Since address headers are *mail.Address pointer, we've also added a *String method that will extract the address string and return a string slice instead
  Additionally we're introducing methods for the actual address headers: GetTo, GetFrom, GetCc and GetBcc (with a *String counterpart as well). This way the user has full flexibility. Either they use the more "low-level" GetAddrHeader method or the higher level methods for the corresponding address type
2022-11-19 11:22:20 +01:00
02c47184c1
Merge pull request #82 from wneessen/bugfix/81_error-from-body-writer-is-ignored
#81: Fix error handling in body writer
2022-11-19 10:03:26 +01:00
47eb7b582b
#81: Fix error handling in body writer
The error handling in the msgWriter.writeBody() method was not working properly. We basically overwrote the mw.err with nil if the function that followed after a failed write attempt was successful again

This patch fixes #81
2022-11-19 09:55:38 +01:00
957e705f16
Update README.md
Removed obsolete parts from the README and referred to GoDoc and our documenation website.
2022-10-27 14:31:14 +02:00
12191c0c2e
Update README.md
Added DKIM Support to README.md
2022-10-26 20:06:17 +02:00
1ff87db521
Update doc.go
Bump version to 0.3.4
2022-10-26 16:03:02 +02:00
0c0ddd5f23
Merge pull request #78 from wneessen/fix/msgid-too-long
The new messageID generated with #74 is a bit too long by default. Th…
2022-10-26 16:01:33 +02:00
d327ca73e4
The new messageID generated with #76 is a bit too long by default. This patch reduces the length 2022-10-26 15:48:48 +02:00
dd0e3a9a48
Merge pull request #77 from wneessen/feature/76-ability-for-preformated-headers
Add SetHeaderPreformatted() method
2022-10-26 15:45:13 +02:00
2e60d070a6
Add SetHeaderPreformatted() method
With the SetHeaderPreformatted() method we have the ability to set headers that are already preformatted by the user and will not be altered in the mail message output
2022-10-26 15:33:03 +02:00
4250eaf911
Merge pull request #75 from wneessen/fix/74-messageid-generation-not-random-enough
Fixed SetMessageID message ID generation
2022-10-26 14:22:23 +02:00
38627631cf
Test for random.go added 2022-10-26 14:21:00 +02:00
8484e557d0
Replace math/rand with crypto/rand
Since the Windows tests were still failing, we are replacing the random number generation with math/rand with random string generation via crypto/rand
2022-10-26 14:05:25 +02:00
5bf0c10525
Randomness apparently not good enough for windows. Tests were failing. This fix improves it 2022-10-26 13:43:51 +02:00
021e003e78
Closes #74
This fix makes sure that generated message IDs via SetMessageID() are truly random and unique
2022-10-26 11:59:03 +02:00
c321aeeccc
Update doc.go 2022-10-25 17:04:30 +02:00
6df19e9463
Merge pull request #70 from wneessen/feature/middleware-type
Introducing MiddlewareType and WriteToSkipMiddleware
2022-10-25 17:04:04 +02:00
2bd6851c78
Fix in the storage of the original Middleware 2022-10-25 16:56:40 +02:00
6f93e5835e
Introducing MiddlewareType and WriteToSkipMiddleware
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

Therefore, this PR 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

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 to be skipped
2022-10-25 16:42:18 +02:00