Postal: Mail Server?

Created on 28 Apr 2017  路  7Comments  路  Source: postalhq/postal

Can this be used as a mail server? The introduction is not very clear. For example, i have a domain (mysupercooldomain.com). Can i run postal on a VPS and just use it as a regular mail server ? and use mail client (outlook...) to connect to it?

Most helpful comment

@ConneXNL I'll start by saying that Postal is not designed to handle your "common" email. It is simply designed to send large swathes of email, doing exactly the same thing as SendGrid or MailGun except in an open source and self-hosted way.

In Postal, you can setup routes that determine what happens when an incoming email gets received. They can either be turned into a Web request, or forwarded to another email address.

For example, if you sent out a mass email from the address "[email protected]", and wanted to forward replies to your mass email (that would be sent to [email protected]) to your own email address, you could setup an SMTP Route that forwards any emails received (incoming) to your email address. This means you no longer have to send emails from "noreply" addresses, and can appropriately handle responses.

It also allows you to handle cases when, for example, someone replies to a promotional email with the subject "Unsubscribe". Normally, this email would bounce, however you could pass this information onto a HTTP endpoint (via a webhook) that automatically unsubscribes people from your mailing lists.

Postal does _not_ store the incoming emails in a mailbox, and does not expose them via a MDA like Dovecot, nor should it. Postal is design to replace large scale mail delivery infrastructure that is used in web applications that send mass emails (on the scale of thousands to millions). It is not designed to replace your day to day email account (eg. Gmail) or your business email, nor should it need to. There are many, many, many available services that provide this functionality at a much higher reliability than that could be achieved from self hosting the service yourself.

All 7 comments

It _can_ receive incoming emails, however you will need to forward these on to somewhere else, for example another email address or mail server. Postal does not provide mailboxes or IMAP/POP3. You cannot connect to Postal and receive email messages via Outlook etc.

I'm just wondering why postal has incoming email capability, is there a particular reason for this seeing that it doesn't offer mailboxes.

If you run a web application that needs to accept incoming e-mail you might use it with the HTTP endpoints to convert incoming emails into HTTP requests. You can also use it to redirect mail to other mail servers (either using SMTP or to another e-mail address).

@adamcooke I now understand postal does not have IMAP support but I don't understand how to make it work with common use cases. Should this be combined with something like dovecot? If so, what are the steps to link them up?

Or maybe a simpler use case. Is it possible to use a Gmail account to receive the messages sent to [email protected] and setup Gmail to send valid emails as [email protected] via postal?

I also got confused by the atech/php-postal. Is it also possible to simply use the php mail()? Can I just connect to SMTP to send emails from PHP?

Is postal a replacement for something like exim? Or are to two not trying to do the same thing?

As you can see, I still have a hard time to understand what role postal has and what it has not, and how and with what to integrate it to get common business email support (receive / archive incoming email support & send emails with a company domain).

It would really help if there is something about this in the docs as I think many people will think it's a full email solution at first sight.

@ConneXNL I'll start by saying that Postal is not designed to handle your "common" email. It is simply designed to send large swathes of email, doing exactly the same thing as SendGrid or MailGun except in an open source and self-hosted way.

In Postal, you can setup routes that determine what happens when an incoming email gets received. They can either be turned into a Web request, or forwarded to another email address.

For example, if you sent out a mass email from the address "[email protected]", and wanted to forward replies to your mass email (that would be sent to [email protected]) to your own email address, you could setup an SMTP Route that forwards any emails received (incoming) to your email address. This means you no longer have to send emails from "noreply" addresses, and can appropriately handle responses.

It also allows you to handle cases when, for example, someone replies to a promotional email with the subject "Unsubscribe". Normally, this email would bounce, however you could pass this information onto a HTTP endpoint (via a webhook) that automatically unsubscribes people from your mailing lists.

Postal does _not_ store the incoming emails in a mailbox, and does not expose them via a MDA like Dovecot, nor should it. Postal is design to replace large scale mail delivery infrastructure that is used in web applications that send mass emails (on the scale of thousands to millions). It is not designed to replace your day to day email account (eg. Gmail) or your business email, nor should it need to. There are many, many, many available services that provide this functionality at a much higher reliability than that could be achieved from self hosting the service yourself.

So basically, say I have a working email domain and website, all hosted reliably, I could stop sending my newsletter from those resources and start using a 3rd party like sendgrid or roll my own with postal while continuing to use whatever service I use for my day to day emails, right?
The benefit of postal vs. rolling my own postfix solution would be the possibility to create companies and users, the tracking, API, endpoints, etc. etc. ?

@ovizii Yes, that's correct. The benefit of Postal is the increased administrative control and insight you have into mail delivery vs that of a plain postfix install. It's basically postfix with a nice GUI and easy configuration.

I would say that, if you are sending a large set of emails, say anything past 50, you should be doing so via a service that is dedicated to doing that. Sending mass emails or newsletters from your own personal email account will only negatively impact the deliverability of your own personal email, and potentially your standing with your email provider (who may have rate limits in place).

A better solution would be to setup Postal (or sign up for the free plan of SendGrid unless you are relatively verse in Linux administration), and setup your domain in it. You can then add Postal or SendGrid's SMTP Relay as a send only email account with a dedicated email address in Outlook or another email client and use this to send your mass emails and newsletters.

Be aware that if you are sending any less than 1000 or so (probably even more), then you are much better off going with the SendGrid solution. Email is very vulnerable to a "warm up period" where receiving ISPs learn the quality of the emails coming from a certain service and/or IP address and are a lot more skeptical of emails coming from servers that they haven't seen a large quantity of email from yet. You'll also need to ensure that your own IPs stay off block lists, something SendGrid does for you.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

harshweo picture harshweo  路  6Comments

destroyer998 picture destroyer998  路  5Comments

shinebayar-g picture shinebayar-g  路  3Comments

igerzog picture igerzog  路  5Comments

BlueHatbRit picture BlueHatbRit  路  3Comments