Hacker News Reader

Comment by davnicwil | Hacker News Reader

This looks really good, but it mentions it uses AWS Simple Email Service to actually send the emails.

I was under the impression that one of the big value adds of the more expensive email services is that, basically, they work on solving the issue of avoiding your email landing in spam, whereas if you use a more 'direct' commodity service like AWS Simple Email Service or other cloud equivalents you have to kind of solve that problem yourself which is really, really hard and hence not worth the saving.

Is that roughly true? Or do I have it wrong?

View on HN

Tangentially related to this but I felt it added to your comment - SES is great for sending emails but horrendous as far as reading received emails goes..which makes sense since SES is better suited for transactional/mass emailing.

In any case, I decided to build myself an SES email client which reads emails from S3. I'm looking for collaborators @ https://github.com/saiorama/ses-email-client/.

The idea is to make an App Store for emails. The first use case I've solved for is give users unlimited disposable emails on their own domain - like your personal Mailinator.

If you would like to try it out for your own side project, drop me a note @ https://shared-inbox.landen.co/.

Yes, that's true. For example, handling soft bounces correctly. That's when SMTP doesn't give an error, but you later get an email indicating a delivery failure. At large volumes, you really need to handle those emails correctly to stay off of blacklists.

Similar, you should have caps on the number of simultaneous outbound SMTP connections to the same domain. And things like knowing which failures are temporary, which are permanent, and when to automatically unsubscribe an email. (after X temp failures over X time period, etc).

Not being routed to Spam is largely a two-step process, which is of moderate complexity in SES, but if you're browsing GitHub you can probably handle it:

* Setting up DKIM and SPF - Amazon makes this relatively painless, particularly if you're managing DNS in Route53

* Not spamming

* convince the other users of your IP block to not hit spamtraps.

I used to work at Mailgun. Believe me, there's a lot more to getting your mail delivered. Simply configuring DNS stopped being enough maybe around 2006-08.

I think you have it backwards though. if you use a big player like AWS or Azure or GCP, you can be pretty sure your mail will get to inbox and not in the spam folder, not the other way around I think. DIY is a little harder

I think the previous comment was potentially more correct.

Typically for low volume sending it doesn't matter. For high-volume sending you need to get the IPs, domains, and security controls set up correctly to reduce how much you're seen as spam.

AWS SES will allow you to configure this all, but you need to know how. Something like SendGrid (not a small player) will be more expensive, but will provide usability features on top and guide you through that setup of that solid foundation a little more.

Ultimately the reputation comes down to the organisation authoring the email (not the email service provider), as they are the ones doing well or badly on the quality of the email they send.

Not true. Inbox placement requires vigilance and monitoring of every user on your IP. AWS is so mixed that is an intractable problem.

You can "bring your own IP" or lease a dedicated IP address for $25/month. I'm not sure how effective it is, but the option is there.

If you're sending a lot of email every day, having dedicated IPs is an important piece of owning your sender reputation. A shared IP is only as good as the email service provider's ability to prevent people from sending spam on their platform. In a system full of black boxes that can have sudden and hard to fix impacts on your business if you rely a lot on email, eliminating one black box (the behavior of other customers on your shared IP) can be a huge risk reduction.

In the past our domain was blocked by one of the top free email providers - we sent about 1 email per day at the time - because we sent email from an IP owned by a hosting provider who also owned another IP that in the past had sent spam. That was the reason given. Whitelisting and adding as a contact didn't allow us to even receive emails from ourselves, to our own email address (over a decade old at the time) with that provider. Our _domain_ has never had spam sent from it, never appeared in a blacklist, and the IP address itself was clean.

So yes, own the IP [and do all the regular SPF, DKIM and such], but be aware that is possibly nowhere near enough.

Reply on news.ycombinator.com