Postal: Open source mail delivery platform, alternative to Mailgun or Sendgrid

Developing and managing your own system, like the OP did, takes a lot of time and energy - all of that, when calculated, costs a lot more :)

Do you have a citation for this?

Absolutely, this is done on AWS with EIPs (elastic ip's). You can migrate an EIP between instances via the AWS API and the change takes effect nearly instantly.

As OP said, there are also things to consider, such as IP reputation, etc... I've done higher volume mailing from a tiny server just like OP, but we also had a couple huge slices of a /24 and pile of /16 net blocks GRE tunneled and used different blocks of addresses for different types of mail. It's not as simple as just setting this up and forgetting it, there's a good bit of arcane knowledge required to do it right. If you're sending millions of messages per day, you cannot afford to burn a bunch of IP addresses because you triggered grey/blacklists for major ISPs or email providers. Shit, these days, you can't afford to burn IP addresses, period. They are officially exhausted. If you HAVE to hit a user's inbox, you can assuredly afford to spend a few grand setting it up right, and then reap the rewards for months/years afterwards for very little recurring cost. Just my two cents, as someone who built a single server to send millions of messages per day.

This is a major risk of outsourcing part of your operations. You probably shouldn't do this to the core of your business, as you lose control over problems. But sending marketing e-mails usually is not the core of business, unless one is selling the service of sending e-mails.

If emails are a part of your core business, you should have a business continuity plan for this situation. That may be to fall back to another service, or even a temporary in-house server.

Of course, if it's that important, then you'd be foolish to not have invested in a better solution, or to not have a proper SLA with a third party.

That's why you always set up a local mail server that delivers onwards to these services. I documented how to do that with Haraka here: https://baudehlo.com/2016/07/26/setting-up-haraka-to-send-to...

If they aren't paying for a dedicated IP, those emails would be going out across the shared IP pool, and a particular IP's reputation would be affected be everyone who's email went out via that IP.

Same here. I've moved away from paying for a dedicated IP because it seemed a bit redundant.

I used to use Mailgun for sending out licences for my product. I got a lot of people saying they had never arrived, especially Microsoft addresses and Chinese ones. This continued despite repeated complaints and IP switches. I switched to sending through Fastmail and have never had a problem since.

Paraphrasing Oscar Wilde, every IP address has a past; in theory, an email service will ensure that the IP they give you has a clean bill of health (not marked in blacklists and such), whereas your ISP or VPS provider may not.

That depends on who you are.

Mailgun will do some chores for you, for a fee. If those chores are things you can do in your sleep, fine! Mailgun does nothing magic.

It depends. Most hosting providers will either discourage you or prevent you from relaying messages from your servers, so that is something you need to check for. Also, you'll want to make sure that your dedicated IP is persistent and won't be lost across reboots. Once you establish a good sending reputation, that's valuable in making sure your messages reach the Inbox.

In the case of Mailgun, you should be assigned an IP with a neutral reputation. For example, before dedicated IPs are reassigned we leave them dormant for at least a month, usually much longer, before assigning to a new customer.

Hi, we've been seeing problems like this with Mailgun for about a year (with the support ticket record to show for it) and I'd love to get in touch. FYI your email address is not currently visible in your profile (should be in the 'about' section).

Sure. Until they email you your account is "temporarily suspended due to some spam complains" and before you find out some angry customer felt that tmher refund process took too long and filter her email to see yours and click "mark as spam" each email and you scramble to setup your own mailservers before you let employees go because your company is unable to send a single email to make a single sale this month...

Until then, all is fine I agree.

You need to configure SPF and DKIM, irrelevant of what reputation and service you have.

I think AT&T was also the reason I started using a bulk mail delivery service for my low volume personal mail when 1&1 migrated their datacenter after I had been using them for a decade or something (thereby changing my IP address).

This sounds like a cryptographic way to achieve the aliasing scheme many people already use, e.g "chatmasta+hackernews@gmail.com".

Your proposal requires at least the status quo (aliased email address at signup), but the problem is it also requires cooperation of the receiver's email provider (e.g. gmail) and the sender's email provider. You are unlikely to ever see any new standard adopted by all major email providers, unless it came through a standards committee.

But your idea is interesting. Perhaps you could lower the cost of adoption by replacing the dependency on TLS/SSL with some sort of pgp signing scheme. This way all the "protocol" happens within the message body, so email providers do not need to adopt a new standard. As long as at least one website and one user implement the protocol, it can work without any cooperation from third parties.

As an aside, it would also be nice if password managers included functionality around generating temporary/isolated email addresses.

I think overall ISPs do a very good job at fighting spam. Compared to a decade and a half ago, I would call it a minimal problem.

My greatest fear is that Google and Facebook will co-opt email and charge money for companies to get access. Google has already made some progress with this by selling ads in Gmail that look like email while pushing commercial messages in to other inboxes.

This is bad because it penalizes companies with low margins while shifting the advantage to those who are able to squeeze more money out of the users (you can see the effect of this on Google Search, Facebook, and now Amazon. It isn't pretty.)

> We really need a better solution to fighting spam.

I rarely receive email spam these days. The spam I get is on my voice line. I'm getting several robocalls per day. If you have the skills to work on this stuff, I'd love to see a solution to phone call spam because email spam feels solved.

I pondered something similar once.

I'd start with the "email postage" proposal—the one where either a proof-of-work or physical payment (which can also be digital, e.g. a Bitcoin private key) is required to get an MTA to take your message. This proposal was declared unworkable due to rendering high-volume transactional email impossible.

But then:

1. as you say here, divide everyone's email account into a set of "channels" (i.e. subaddresses in a+b@c form, that each have a corresponding message signing key), with one or more published or well-known channels, and then individual private channels for each contact/list, or for each conversation(!);

2. make MTAs aware of "channels", and extend both SMTP and email web services to allow users to configure their provider's end-of-line MTA, over-the-wire, to set the amount of "postage" required to message each channel they own. (This way, the MTA doesn't have to be aware of the distinction between private and public channels; they're just destination addresses with a stored config parameter.)

3. make the MTAs that use channels, reject any Internet message directed to the base address without a channel. (Messages generated by the MTA itself can arrive without a channel.)

4. Set the clients' default new-channel configurations such that public channels have a cost, and private channels are free.

5. In email clients, add a "Subscribe" or "Allow" action-bar item to messages that identify themselves as email-confirmation/newsletter-opt-in emails (presumably with a header), that, when clicked, creates a new channel for the sender, and replies to the message with the signing key you want them to use attached. (All this would be hidden from view; the reply message wouldn't end up in your Sent Items.)

6. In transactional-email-sending services like Sendgrid/Postmark/etc., create a distinction between "opt-in messages" and "ongoing transactional messages"; allow each account to send one "opt-in" email to each previously-unknown destination-address (and charge for this); but then, for that account, put that destination-address into holding state, where the account can't send them any "ongoing transactional messages", until the email-sending service receives the user's conversation key. (You probably want to allow accounts to re-send the opt-in email after a 24-hour-cooldown, though. Though they'd have to pay again!)

7. In any product/service backend that uses a transactional-email service, consider new signups unconfirmed until the transactional-service reports (by polling or webhook or whatever) that the user has replied with a key and is now in the "authenticated and free to send to" state.

A bit complicated in the initial changes, but in the ongoing state it's nearly ideal: it costs money to initiate contact with an address, or to continue pestering an address that doesn't want to speak with you, but not to send messages to someone that wants to hear from you. (Though, a user can "unsubscribe" from your list simply by telling their MTA to begin charging you to deliver to their channel again—maybe, UI-wise, by just deleting the channel. Transactional-email sending services could detect the bounced-with-payment-required delivery error, and put the user automatically into an "unsubscribed" state, which could webhook you to let you know!)

I found this service a few days ago to monitor our own deliverability. It allows you to test if your emails are delivered by the most common ESPs: https://glockapps.com

(I do not have anything to do with the product or team behind it)

The term to search for is "RBL" (real time blacklist). Search for "check rbl" to find interactive sites, or maybe "check rbl github" for code that you can use yourself (though you may have to sign up for several services if you go that route).

Neither, though, helps with checking if one of the big providers, like Google, would not like your IP. For those, you have to send an email and watch/parse the SMTP error responses.

Even so, this may not be very beneficial.

In years past, many RBLs would categorize IP Addresses by type. e.g. dynamic IPs assigned to DSL/Cable subscribers. This would enable a receving SMTP server to check if the email came from an ISP subscriber, rather than an email server. If so, it was usually a good guage that the email was "spammy", because it was sent by a subscriber's infected computer.

In this sense, it was (and may still be) possible to simply block, or at least score differently, email from any/all AWS Elasic IPs.

You can check the Spamhaus lists. It's a non-profit org dedicated to all-things-spam. https://www.spamhaus.org/

http://mxtoolbox.com/blacklists.aspx per https://news.ycombinator.com/item?id=9855145

https://senderscore.org/ per https://news.ycombinator.com/item?id=9156312

http://whatismyipaddress.com/blacklist-check per https://news.ycombinator.com/item?id=11329371

http://multirbl.valli.org/ per https://news.ycombinator.com/item?id=11330382

In practice, while there are some services which will purport to tell you an IP's reputation, their output isn't well correlated with actual delivery outcomes at scale (depending, to some extent, on what domains you're sending to).

This is because the big consumer mailbox providers often don't rely on public datasources for assessing reputation, and because reputation is tracked at the domain level, in addition to - or sometimes instead of - the IP level. For example, there have been some indications from Gmail that they no longer use IP reputation at all, starting a year or two ago.

And re: blacklists: +1 to Spamhaus, but in practice it's one of very few blacklists that have meaningful impact to net delivery.

I think you meant to link here:

https://cuttlefish.io https://github.com/mlandauer/cuttlefish

Unless you are doing a TON of sending, you are better off with a shared ip since it will have a known reputation. That is assuming that the provider is maintaining the integrity of those allowed to send with that ip. I haven't used sendgrid, but mailgun has been good about moving me off of any ip I don't like. Although I wish they were more proactive about it, I have setup a weekly monitoring script to check a bunch of the blacklists. If there are any issues, I will have them move me. And I am still on the free tier so I can't complain.

Spam sucks, but don't waste your time reporting it to federal agencies. In practice, 'unsolicited' isn't a high enough bar for them to care - it has to be overtly fraudulent, malicious, etc. in order to have a shot at getting attention.

Judging from the amount of it the sending email portion is not what spammers struggle with. It's the "maintain your own IP with a great reputation" part. How would Postal help?

Well from the install directions they recommend 8GB of memory for the server. A simpler SMTP server like Postfix or Exim can do with much fewer resources, and a spam operation doesn't care about abiding by protocol for redelivery attempts, they just fire and forget and mostly opt for direct SMTP delivery.

Because their IP address reputation would plummet instantly.

The codebase is a bit of a horror, though, of the old "PHP+SQL+HTML mixed in a blender" variety. I went in to make a few mods at one point and it was pretty scary.

Sentopia.net founder here. I agree that the codebase could be better, a lot better.. but we have made heavy modifications and it's not a problem anymore, I should add that we have tried to work together with Sendy.co developers but seems our emails are being ignored. Sendy is a platform, and a good one at that. but our value is on our SMTP server pools and their reputation as others have mentioned. We are always looking at new platforms like postal, that we can jump on board with if it means a better user experience for our clients.

You're quite right - I've updated the comment and my profile to include that information. Thanks for mentioning.

We're already on AlternativeTo but unfortunately below the fold on most of our competitors.

Fair. To a certain mindset, "self-hosted" is its own advantage -- but to pick a couple of advantages out of thin air:

   + Free: I can run Postal on my own hardware, with no usage limits or costs other than the VPS or AWS costs (which I'm paying anyway)
   + Independent: I'm not relying on a third-party to provide core features. If SendGrid goes down there's nothing I can do about it
   + Private: Maybe I don't want to hand over a list of my user's email addresses to SendGrid.

Self-hosting services means I maintain control over them. It's a tradeoff, and you may value control less than, say, convenience. YMMV.