Postal: 📨 A fully featured open source mail delivery platform for incoming & outgoing e-mail

[girish]

Yeah, I think postal is a relay server. Does it include a SMTP server or does it integrate with an existing one?

[jdaviescoates]

Oooh, I just realised Postal is now run by Krystal who I'm aware of because they are on my list of Eco VPS providers. I now like them even more knowing that they also maintain cool things like Postal!

[jdaviescoates]

@girish said in Postal: A fully featured open source mail delivery platform for incoming & outgoing e-mail:

Does it include a SMTP server

Think it might, see https://docs.postalserver.io/welcome/feature-list where it says:

Send messages to the SMTP server or using the HTTP API.

[marcusquinn]

Currently using ElasticMail, but all these costs add up, this would definitely get some use if we get to packaging it.

[girish]

@marcusquinn Services like Elasticmail provide deliverability. Postal won't solve that since it will send either via the VPS IP or via some relay (like Elasticmail). Unfortunately, no way out of those costs.

[privsec]

Additional and descriptive statistics accessible by domain is a swell add to the platform of cloudron

[marcusquinn]

@girish Most of those services use shared IP addresses, and upsell dedicated IPs on the basis that their shared IPs might not be as reliable for delivery reputation.

In my experience, none of the relays can help deliverability from their reputation alone, it's the tools (like Postal) they offer that help you make sure you're not sending marketing emails to people that unsubscribe, mark the emails as spam, or bouncing.

Deliverability is more to do with domain and email address reputation, content and minimal unsubscribes or abuse reports.

Any new domain email address to be used for mass-mailing should really be warmed up, there's a whole industry of platforms offering that service, due to the need, and explaining it better themselves:

• https://www.warmupinbox.com/

I realise building a good reputation for email delivery is hard, but that's because bad people ruin things for the rest of us, but Postal is a good anti-lockin tool for businesses sending emails, because otherwise they get locked in to their reputation being somewhat tied to the 3rd-party SaaS relay.

Plus, it's another thing that Cloudron pro users could resell to their clients, save money from 3rd-party relays, and use your own separate Cloudrons for mail relay.

After all that, I think it's still a worthy candidate app for many online Pros

[micmc]

@marcusquinn I absolutely second all that is said here above.
Postal would a 'feature' that would greatly enhance the CR offer.

[marcusquinn]

Part of the problem with self-hosted email sending deliverability is the lack of that data on bounces, marked as spam and unsubscribe rates, so Postal might help with that, and levelling the field against the tech-giant dominance over this one specific area that they know is one of their leverage tools to diminish the internet for those that don't fall into line.

[james]

I have looked into it.
When packaging postal we could bind port 25 to 127.0.0.1 and not map it in the CloudronManifest.json.
But we lose many of features the people want to use postal for.

• no incoming mail
• no bounce handling (unless you add MX and forwarding)
• no suppression list / full delivery feedback when using an external relay https://github.com/postalserver/postal/issues/497#issuecomment-365283308

For outbound-only the postal API or internal docker IP to access the internal postal SMTP could be used and this sound more like a service compared to a singular app.

Another big issue - https://github.com/postalserver/postal/issues/48#issuecomment-310317594

What about authentication on SMTP relays?
That isn't supported. You should configure your relay to allow connections from the IP of your Postal server.

The amount of features lost and lack of auth for SMTP relays is a mayor roadblock.

So I came to conclusion that we will not package postal for Cloudron.