search

wneessen / go-mail

📧 Easy to use, yet comprehensive library for sending mails with Go
https://go-mail.dev
MIT License
571 stars 44 forks source link

Fork the net/smtp package from stdlib into go-mail #97

Closed wneessen closed 1 year ago

wneessen commented 1 year ago

Is your feature request related to a problem? Please describe.

go-mail relies on the net/smtp package of the Go stdlib. Unfortunately this lib is in feature freeze mode, so that enhancing/extending the package is not possible. This restricts us - at least to a certain level - as we can't add features that would be useful for go-mail (thinking about giving back SMTP status codes or perform debug-logging on the client level).

For that reason it might be a good idea for go-mail to fork the net/smtp package into our own code base. This would allow us to start with a solid code base that we already rely on but it would also allow us to add features and extend the code.

License-wise the BSD-3 license of the Go project would allow this and since the Go stdlib is in code freeze, we don't need to worry about keeping up with the original code - monitoring for possible security fixes should be put into place maybe.

Describe the solution you'd like

Get net/smtp forked into go-mail and adjust any code that currently use net/smtp to use our internal fork instead.

Describe alternatives you've considered

N/A

Additional context

N/A

james-d-elliott commented 1 year ago

This is probably a good idea for any minor adjustments that need to occur to make the underlying API more useful/usable/exposed. Being able to get information that would otherwise be inaccessible is a huge plus, as well as the ability to get response codes.

I think the change itself looks good. One potential point is inclusion of the license. Maybe you could just include the license from here as a file in the smtp dir? I'm not a legal expert, and I doubt it will be an issue since it wasn't expressly removed from the headers etc, but I think that probably there is benefit in including the license in its entirety.

You should probably also include the commit sha1 of the go stdlib which you forked from in the commit that is finally merged into master too. Even though it's technically frozen it will make finding a diff very simple for anyone if those files ever change.

A potential idea for the future would be to make the smtp portion a completely isolated git repo. I don't think this is essential by any means but it makes it relatively simple to identify a change to the fork rather than a change potentially getting mixed in with an otherwise fine PR (edit: technically this has the disadvantage of making changes to the fork is more cumbersome since if you make breaking changes you have to maintain versions and have to make PR's in TWO repos).

wneessen commented 1 year ago

Thanks for your assessment, James. Indeed good points - especially the license one and the commit SHA1.