Live data from Hacker News

Show HN: SESS – Simple Email Sending Service

sess.email

21–30 of 43 posts

Re: Show HN: SESS – Simple Email Sending Service

#22
post #18

Looks great, but email composition is only half the battle. The page is silent on what, if anything, is being done to help deliverability. Does the site have any kind of relationship with the big ESPs? How 'clean' are the IPs right now? What, if any, mitigation is in place for the sending IPs inevitable reputation degredation? Or is a EDS being used to actually send the emails?

SESS is tightly wired to use SES (AWS). We do a bunch of algorithmic checks to validate email/domain validity plus assessing the risk-factor of uploaded email list. If you have a clean list deliverability is closer to 100%.

Edit: Thanks for the note. I will make a mention of the deliverability on the site.

Re: Show HN: SESS – Simple Email Sending Service

#24

What constitutes a "valid business email", exactly? I entered one, clicked "verify", and was warned to "enter a valid business email." I assure you, I did. What's the trouble?

A valid business email is one where you should be able to receive and send mails. If you have a 'catch all' email id, the system does not accept that.

Having said that i must say our algorithm is deliberately a bit aggressive (so as to prevent spam).

Your email could very well be a false positive. Could you write to support@sess.email from the business email in question. I'll be happy to look into it and whitelist it.

Re: Show HN: SESS – Simple Email Sending Service

#26

I get a: 'e {code: "app/duplicate-app", message: "Firebase: Firebase App named '[DEFAULT]' already exists (app/duplicate-app)."' in console when trying to verify my email.

Could you write to support@sess.email with a screenshot. Im curious to look into whats happening here. Thanks.

Re: Show HN: SESS – Simple Email Sending Service

#27
post #24

What constitutes a "valid business email", exactly? I entered one, clicked "verify", and was warned to "enter a valid business email." I assure you, I did. What's the trouble?

A valid business email is one where you should be able to receive and send mails. If you have a 'catch all' email id, the system does not accept that. Having said that i must say our algorithm is deliberately a bit aggressive (so as to prevent spam). Your email could very well be a false positive. Could you write to support@sess.email from the business email in question. I'll be happy to look into it and whitelist it…

What technical means do you use to detect a catch-all address? I know of no reliable method for that purpose, since receiving server cooperation would be required and could not be trusted.

Re: Show HN: SESS – Simple Email Sending Service

#28
post #26

I get a: 'e {code: "app/duplicate-app", message: "Firebase: Firebase App named '[DEFAULT]' already exists (app/duplicate-app)."' in console when trying to verify my email.

Could you write to support@sess.email with a screenshot. Im curious to look into whats happening here. Thanks.

done!

Re: Show HN: SESS – Simple Email Sending Service

#30
post #11

My only concern with trying this as someone just starting out with email marketing is that I don't know my SBUR rate... in fact I would assume that the first ever email to a new population (even if legitimate) is bound to have a far higher rate given errors in data collection (say collected on paper, leading to bad email addresses and bounces) and keen unsubscribers. Then I'm successfully banned and have to go to ano…

Let me rephrase your query. If you send 2 emails and 1 bounces, then your SBUR would be 50% and so will you be banned? NO. We predicted this would happen. The SBUR doesn't kick in for the first few thousand mails. Over time your list gets cleaner (because we keep track of bounces, unsubscribes and dont send them emails from next time on.) (I'm one of the engineers who developed SESS.)

Dirty spammer hack: include 50% of recipients as addresses you control, and that won't ever bounce, complain, or unsubscribe. That pushes SBUR down, likely below threshold.

These are often addresses created manually by 'click farmers' so they don't have obvious patterns which could enable an email service provider to identify them. (I'm still working on figuring out ways to detect this...)

Or, send spam to a new address via another service, then only use SESS to send to the ones who had opened or clicked on the other service. This is known as 'waterfalling'. Using this method, bounce rates can approach zero, and complaints/unsubscribes are likely to stay below 1% each - but make no mistake, ISPs can and will often still detect the email as spam.

You will need more complex ways to detect approaches like these, as well as other forms of spam/abuse. I would suggest starting with looking at thresholds for bounces, unsubscribes, and complaints independently - sometimes complaint rates of 0.1% can be a strong indicator of spam.

Related - don't limit your contractually-defined recourse to just SBUR rates. I would recommend including terms that allow you to ban or suspend users for any form of spam or abusive activity, "in the sole judgement of SESS.EMAIL" or similar. (I am not a lawyer and this is not legal advice.)

Post reply on HN