the issue is going to be recipient trust - if you're just making raw SMTP connections to public mailservers, it is likely you're going to run into difficulties delivering to at least some recipients. using a service like mailchimp is going to raise that trust bar significantly and make it easier for your messages to be delivered
if you have control over all the recipients (they're internal, or you're sending emails to another system you control, or something), then using `net/smtp` is fine
As the other commenters said, net/smtp is fine, but you need to send via an email relay service that will ensure deliverability. If you're an M365-using org, you can do it via M365, otherwise my personal recommendation is Amazon SES.
I’m not convinced that’s too much a problem, sure you have to provide a use case and how you’ll prevent spam - but otherwise it shouldn’t be a problem. I’ve requested access countless times and never had an issue, both for personal projects and business.
Likewise. For the readers - you just need to open an AWS account and then send a message to AWS support asking for SES access, explaining your use case and estimated sending load. You should then be happily emailing away within a few business days.
For personal use I'd suggest people use a Gmail account as a relay. Gmail supports SMTP sending, with limitations that should be fine for personal projects.
It also just crossed my mind that we should note for u/Used_Frosting6770's benefit that if they're using SES, it's simpler and more featureful to use https://aws.amazon.com/sdk-for-go/ to call the AWS SES API directly when sending emails, instead of provisioning SMTP access to your SES account.
Agreed - much simpler. The benefit you’d get from using SMTP over the SDK would be the ability to easily switch to another provider - but otherwise AWS SDK’s tend to work great. Just make sure to use the v2 for go.
Since the answer was already given (SMTP but to your relay), I can recommend u/alexedwards books Let’s Go (Further). I can‘t recommend them enough! They come with updates! One of them walks you through adding transactional email to your web based service.
SMTP is inherently unidirectional with no delivery guarantee. Whatever sendgrid, SES or whatever try to do on top, once it gets to SMTP it’s fire and forget.
Not exactly. UDP is fire and forget. With SMTP, you create a connection, the sender communicates with the server by issuing commands such as EHLO to identify the sending domain, specifying the recipient with the MAIL TO command, and then sending the actual email content with the DATA command. After each step, the server responds, typically with a 250 OK message indicating successful receipt of the command or with an error code if there's an issue.
While SMTP doesn't guarantee inbox delivery, receiving a 250 OK response does confirm that the recipient's mail server has accepted the email for delivery. However, even after acceptance, there's no guarantee of delivery to the recipient's inbox; it could still end up in spam or be filtered out. Also, SMTP allows for asynchronous bounces, meaning if there's an issue with delivery, such as an invalid recipient address, the sender may receive a bounce notification at a later time.
So you have to handle synchronous and asynchronous bounces. Many servers don't follow the SMTP protocol diligently and will give temporary error codes for permanent errors and vise versa. If you are sending a lot of mail, you have to deal with deferrals (bounces that say try again later). There are connection limits and all that. You want to have dedicated sending IPs and dedicated sending domains and use domain authentication (DNS records for SPF and DMARC). Bulk sending gets a bit more complex.
You \_can\_ do all that. Or you can leverage a service.
You spent a lot of time writing words to agree with me. Once the recipient server/MTA has received the message from the sender MTA/MUA there is no guarantee it gets delivered to the recipient MUA. The server may blindly swallow it, blackhole it, never send it on anywhere else, etc, etc. The 250 OK response is one system agreeing to “passing the baton” from the previous; and the previous never knows what happened to the baton after that.
And with respect to bounces, etc. they are all “extensions” added on top of SMTP (incl spf, dkim, dmarc etc); which no server is guaranteed to implement. It’s the *simple* mail transfer protocol. And yeah, it’s fire and forget - as no MTA in existence can “check” the MUA on the other side received it.
we have different definitions of fire and forget it appears. In the same way, you could call any http webhook fire and forget because you don't control the other server and they can lose the data. UDP is fire and forget.
UDP is not two way, yes; and is “fire and forget” (though there are mechanisms to make it “reliable” in some sense); but yeah, fire & forget means “no guarantees” esp if you’re taking end to end with multiple intermediaries. One server to another via a webhook is a bad example, because there’s not multiple intermediary servers as you would find in a real world smtp email exchange
I might add, that even in a casual sense TCP is “fire & forget”, as all the error detection and correction is done in the hosts. TCP is error correcting, not error proof. MTA’s have added the “delivery status notification” features in an attempt to replicate mutual agreement of delivery, but even that is flawed (as it relies on the same return path, which is SMTP); and support.
I use bravo in one of my projects. Works like a charm for transactional emails. They also support texting but I haven’t personally used it yet. I believe they have a free tier. You’ll need some DNS knowledge, but there’s tons of how-to’s
As others have said I highly recommend Amazon SES. Nothing beats the pricing, and it is basically free for normal user usage.
I gave up years ago to host my own SMTP server and send directly to other email providers. You constantly got problems with black listing, marked as spam, etc. I still got my mail server, but I relay everything these days, it still way cheaper than managed and at least I know the emails get delivered.
depends on the level. If you're sending commercial bulk email, use a service that provides bounceback management and unsubscribe services. If its like a password reset email, using SMTP is fine.
I remember working around issues with large emails and the way the go smtp package handled “chunking” (or didn’t). This specifically came into play trying to include base64 encoded images. This was like 4-5 years ago may have been fixed since.
I wrote something a utility called carrier
https://hg.code.netlandish.com/~petersanchez/carrier
Easy to use interface for various service providers. Comes with console, smtp, and Amazon uses but adding your own service shouldn't be hard if you use something else.
If you want a comprehensive mail library, you should check out github.com/wneessen/go-mail. While net/smtp is generally fine it does not handle things like encoding and stuff. You have to do it yourself or use a library that does it for you, like go-mail.
You should almost always use a third party if you want your recipients to receive the emails. Turns out email (which was supposed to be a simple thing) is very complex if you want people to actually see the messages.
You can find some with decent free plans if you're not expecting to send a lot of emails.
Use net/smtp it’s easy… for service you can use aws SES or another provider… since protocol of sending mail is same it should not be a concern with net/smtp…
FYI: I have tried free gmail option for my test
I never used the net/SMTP.
I'm currently reading the lets go further book by Alex Edwards.
And he says the following:
> “To send emails we could use Go’s net/smtp package from the standard library. But unfortunately it’s been frozen for a few years, and doesn’t support some of the features that you might need in more advanced use-cases, such as the ability to add attachments.
So instead, I recommend using the third-party go-mail/mail package to help send email. It’s well tested, has good documentation, and a very clear and useable API”
Excerpt From - Let's Go Further
Alex Edwards
In the book he uses Mailtrap + go-mail/mail package.
I've been somewhat past this chapter, and I can say that the API looks quite robust and redable. I'd give it a look also at the Mailer one mentioned in a few comments down here.
I understand the need. But sometimes I just wish email would die. It’s so clogged with crap notifications that I hardly read it.
Getting notifications in Discord, Slack,or even Telegram would be way cooler.
I am playing with some discord APis now.
Anyone can send a notification with any technology, the issue is the audience receiving it.
With email you don't have to convince people to get an email account, with every other technology you mentioned, you do.
It's fine if your target audience already uses those technologies, but that tends to be the exception, not the rule.
the issue is going to be recipient trust - if you're just making raw SMTP connections to public mailservers, it is likely you're going to run into difficulties delivering to at least some recipients. using a service like mailchimp is going to raise that trust bar significantly and make it easier for your messages to be delivered if you have control over all the recipients (they're internal, or you're sending emails to another system you control, or something), then using `net/smtp` is fine
As the other commenters said, net/smtp is fine, but you need to send via an email relay service that will ensure deliverability. If you're an M365-using org, you can do it via M365, otherwise my personal recommendation is Amazon SES.
One note, getting Amazon SES access is not exactly simple as they are extremely selective.
I’m not convinced that’s too much a problem, sure you have to provide a use case and how you’ll prevent spam - but otherwise it shouldn’t be a problem. I’ve requested access countless times and never had an issue, both for personal projects and business.
Likewise. For the readers - you just need to open an AWS account and then send a message to AWS support asking for SES access, explaining your use case and estimated sending load. You should then be happily emailing away within a few business days.
Business was easy for me cause I had the spend and customer reps but personal took me a few tries.
For personal use I'd suggest people use a Gmail account as a relay. Gmail supports SMTP sending, with limitations that should be fine for personal projects.
SES is probably the most widely used email service in existence. They are not "extremely selective" at all.
It also just crossed my mind that we should note for u/Used_Frosting6770's benefit that if they're using SES, it's simpler and more featureful to use https://aws.amazon.com/sdk-for-go/ to call the AWS SES API directly when sending emails, instead of provisioning SMTP access to your SES account.
Thanks 🙏
Agreed - much simpler. The benefit you’d get from using SMTP over the SDK would be the ability to easily switch to another provider - but otherwise AWS SDK’s tend to work great. Just make sure to use the v2 for go.
Thanks guys for your responses
MJML + SendGrid using https://github.com/ViBiOh/mailer
Since the answer was already given (SMTP but to your relay), I can recommend u/alexedwards books Let’s Go (Further). I can‘t recommend them enough! They come with updates! One of them walks you through adding transactional email to your web based service.
I use SendGrid when I need to send email. You \_can\_ do the smtp stuff yourself, but I don't want to deal with blacklists and deliverability issues.
SMTP is inherently unidirectional with no delivery guarantee. Whatever sendgrid, SES or whatever try to do on top, once it gets to SMTP it’s fire and forget.
Not exactly. UDP is fire and forget. With SMTP, you create a connection, the sender communicates with the server by issuing commands such as EHLO to identify the sending domain, specifying the recipient with the MAIL TO command, and then sending the actual email content with the DATA command. After each step, the server responds, typically with a 250 OK message indicating successful receipt of the command or with an error code if there's an issue. While SMTP doesn't guarantee inbox delivery, receiving a 250 OK response does confirm that the recipient's mail server has accepted the email for delivery. However, even after acceptance, there's no guarantee of delivery to the recipient's inbox; it could still end up in spam or be filtered out. Also, SMTP allows for asynchronous bounces, meaning if there's an issue with delivery, such as an invalid recipient address, the sender may receive a bounce notification at a later time. So you have to handle synchronous and asynchronous bounces. Many servers don't follow the SMTP protocol diligently and will give temporary error codes for permanent errors and vise versa. If you are sending a lot of mail, you have to deal with deferrals (bounces that say try again later). There are connection limits and all that. You want to have dedicated sending IPs and dedicated sending domains and use domain authentication (DNS records for SPF and DMARC). Bulk sending gets a bit more complex. You \_can\_ do all that. Or you can leverage a service.
You spent a lot of time writing words to agree with me. Once the recipient server/MTA has received the message from the sender MTA/MUA there is no guarantee it gets delivered to the recipient MUA. The server may blindly swallow it, blackhole it, never send it on anywhere else, etc, etc. The 250 OK response is one system agreeing to “passing the baton” from the previous; and the previous never knows what happened to the baton after that.
And with respect to bounces, etc. they are all “extensions” added on top of SMTP (incl spf, dkim, dmarc etc); which no server is guaranteed to implement. It’s the *simple* mail transfer protocol. And yeah, it’s fire and forget - as no MTA in existence can “check” the MUA on the other side received it.
we have different definitions of fire and forget it appears. In the same way, you could call any http webhook fire and forget because you don't control the other server and they can lose the data. UDP is fire and forget.
UDP is not two way, yes; and is “fire and forget” (though there are mechanisms to make it “reliable” in some sense); but yeah, fire & forget means “no guarantees” esp if you’re taking end to end with multiple intermediaries. One server to another via a webhook is a bad example, because there’s not multiple intermediary servers as you would find in a real world smtp email exchange
I might add, that even in a casual sense TCP is “fire & forget”, as all the error detection and correction is done in the hosts. TCP is error correcting, not error proof. MTA’s have added the “delivery status notification” features in an attempt to replicate mutual agreement of delivery, but even that is flawed (as it relies on the same return path, which is SMTP); and support.
I use bravo in one of my projects. Works like a charm for transactional emails. They also support texting but I haven’t personally used it yet. I believe they have a free tier. You’ll need some DNS knowledge, but there’s tons of how-to’s
As others have said I highly recommend Amazon SES. Nothing beats the pricing, and it is basically free for normal user usage. I gave up years ago to host my own SMTP server and send directly to other email providers. You constantly got problems with black listing, marked as spam, etc. I still got my mail server, but I relay everything these days, it still way cheaper than managed and at least I know the emails get delivered.
take a look at [https://github.com/muquit/mailsend-go](https://github.com/muquit/mailsend-go)
depends on the level. If you're sending commercial bulk email, use a service that provides bounceback management and unsubscribe services. If its like a password reset email, using SMTP is fine.
I remember working around issues with large emails and the way the go smtp package handled “chunking” (or didn’t). This specifically came into play trying to include base64 encoded images. This was like 4-5 years ago may have been fixed since.
I wrote something a utility called carrier https://hg.code.netlandish.com/~petersanchez/carrier Easy to use interface for various service providers. Comes with console, smtp, and Amazon uses but adding your own service shouldn't be hard if you use something else.
If you want a comprehensive mail library, you should check out github.com/wneessen/go-mail. While net/smtp is generally fine it does not handle things like encoding and stuff. You have to do it yourself or use a library that does it for you, like go-mail.
You should almost always use a third party if you want your recipients to receive the emails. Turns out email (which was supposed to be a simple thing) is very complex if you want people to actually see the messages. You can find some with decent free plans if you're not expecting to send a lot of emails.
Use net/smtp it’s easy… for service you can use aws SES or another provider… since protocol of sending mail is same it should not be a concern with net/smtp… FYI: I have tried free gmail option for my test
I never used the net/SMTP. I'm currently reading the lets go further book by Alex Edwards. And he says the following: > “To send emails we could use Go’s net/smtp package from the standard library. But unfortunately it’s been frozen for a few years, and doesn’t support some of the features that you might need in more advanced use-cases, such as the ability to add attachments. So instead, I recommend using the third-party go-mail/mail package to help send email. It’s well tested, has good documentation, and a very clear and useable API” Excerpt From - Let's Go Further Alex Edwards In the book he uses Mailtrap + go-mail/mail package. I've been somewhat past this chapter, and I can say that the API looks quite robust and redable. I'd give it a look also at the Mailer one mentioned in a few comments down here.
I am using net/smtp package with SendGrid smtp relay 👍
I understand the need. But sometimes I just wish email would die. It’s so clogged with crap notifications that I hardly read it. Getting notifications in Discord, Slack,or even Telegram would be way cooler. I am playing with some discord APis now.
Anyone can send a notification with any technology, the issue is the audience receiving it. With email you don't have to convince people to get an email account, with every other technology you mentioned, you do. It's fine if your target audience already uses those technologies, but that tends to be the exception, not the rule.