Figure out a sustainable email sending solution

[callahad]

Postmark is super fantastic and speedy as hell, but as soon as we hit the frontpage of HN people started entering fake addresses like a@a.com and test@test.com which bounced. Because of the rate of bounces, Postmark suspended our account.

We can't let the bounces continue to come through our platform as it would hurt our sending reputation for our other customers. If you can find a way to verify email addresses being used before emails are sent, you can continue using Postmark, otherwise you will need to send these emails using a different method.

Right now we've fallen back to SendGrid, which is taking upwards of 60 seconds to deliver mail, totally unsuitable for Portier's user. I've set up SPF and DKIM records for Mailgun, so we can try jumping over there in an hour or so, but... this seems like we're on a really shaky foundation.

We don't want to screw over the email service providers, but I also don't know how we could further reduce our bounce rate. Any ideas?

[danny-wu]

Can we have a simple heuristic to detect possibly bogus emails, and have some JavaScript that intercepts the form submission and asks if they're sure?

Possible heuristics:

Username or domain or extension is 1 character
3+ repeated characters
Qwerty runs

[danny-wu]

Can we have a simple heuristic to detect possibly bogus emails, and have some JavaScript that intercepts the form submission and asks if they're sure?

Possible heuristics:

Username or domain or extension is 1 character
3+ repeated characters
Qwerty runs

[callahad]

Since we don't control the submission form (in the general case), we'd have to block this at the broker (backend)... but we could do that. And it'd be more robust, too. A reasonable UX seems obvious: when we detect a suspicious email address, we could just display an error along the lines of "sorry, this doesn't look like a real address" and then either hard-fail or require a CAPTCHA before continuing.

...the trick is figuring out those heuristics, and making decisions about when it's OK to hard-fail. The ones you suggested seem sane for soft-failures. We could also check DNS for an MX record before proceeding, and hard fail if one isn't found, though test.com does publish MX records :/

[callahad]

Since we don't control the submission form (in the general case), we'd have to block this at the broker (backend)... but we could do that. And it'd be more robust, too. A reasonable UX seems obvious: when we detect a suspicious email address, we could just display an error along the lines of "sorry, this doesn't look like a real address" and then either hard-fail or require a CAPTCHA before continuing.

...the trick is figuring out those heuristics, and making decisions about when it's OK to hard-fail. The ones you suggested seem sane for soft-failures. We could also check DNS for an MX record before proceeding, and hard fail if one isn't found, though test.com does publish MX records :/

[stephank]

There's a bunch of stuff we can do. Ideas:

• This ties in with rate limiting (#70).
• We can process bounces, and temporarily blacklist mails.
• We can resolve the MX record ahead of sending the mail.

[stephank]

There's a bunch of stuff we can do. Ideas:

• This ties in with rate limiting (#70).
• We can process bounces, and temporarily blacklist mails.
• We can resolve the MX record ahead of sending the mail.

[flaviusb]

Suggestion: treat a hn referer as probable bogus. Use captcha, or fall back to SendGrid specifically for probable bogus users.

[flaviusb]

Suggestion: treat a hn referer as probable bogus. Use captcha, or fall back to SendGrid specifically for probable bogus users.

[danielcompton]

Sendgrid has an email validation API which should filter out really obviously bad stuff.

[danielcompton]

Sendgrid has an email validation API which should filter out really obviously bad stuff.

[tibu]

If you're checking MX for the domain you should check also A record too as a fallback if MX does not exist. I had issues with this before I found out that the standard allows this (if no MX, use A record to deliver mail)

[tibu]

If you're checking MX for the domain you should check also A record too as a fallback if MX does not exist. I had issues with this before I found out that the standard allows this (if no MX, use A record to deliver mail)