Skip to main content

Infrastructure

Target audience

The target audience for this section are people that are interested in the technical side of the system. If you just want to quickly set up an instance go to the deployment quickstart.

Mailflow Relay is not a standalone piece of software that works in a vacuum. To function correctly it relies on some supporting infrastucture to make it work as expected.

Why not standalone?​

This is the classic "make or buy decision" but for software. Our core value is in providing list management features with an intuitive interface. By not managing configuration of email servers, spam-filtering or monitoring of IP-health we deligate to those that know more then us. We trust that others are better at email then we are and interact with what they have build for us via well-documented APIs. The gained flexibility allows us to iterate on our value proposition faster and to deliver services cheaper1.

System overview​

You can cut the infrastructure into 3 parts:

  • Getting the mails from the outside into MailFlow relay. We call this our ingress.
  • Processing the request and triggering the necessary reactions (like queueing emails).
  • Getting the mails out of MailFlow Relay back into the world. This is our egress.
Flow diagram

Infrastructure Diagram This diagram explains the core functions of the system and how they relate. To get an in-depth explanation of what it all means you can read more here. Considered as an optional deepdive.

Ingress​

The email-ingress is the place where emails from the outside enter our processing pipeline. You can imagine it like an order-counter at a fastfood place. These systems do not actually process the request in any meaningful way but do initial validation and hand over jobs to the downstream workers.

warning

MailFlow Relay does not do any spam-filtering by itself. we rely on our ingress-providers to do filtering and other preflight-checks.

The common point where all ingress types meet is the unified processing pipeline that expects valid parsed IMAP-data. Assuming your system can talk IMAP with us we can add support for it.

Supported sources​

We currently support two ingress providers on a first-party basis:

You need at least one of them to be up and running correctly if you want MailFlow Relay to be able to react to incomming messages.

note

You can run multiple ingress sources at the same time since the ingress side is not stateful (except for service connection details). We currently do not support multiple copies of the same ingress type.

Processing​

The email processing is what MailFlow Relay does. On the highest level it reads the email, decides who should get a copy and forwards it onwards. In practise the processing pipeline has a few more tricks up its proverbial sleeve like filter rules or templating among others but these are all optional.

In the most cases MailFlow Relay will simply create copies of the email and send them out to all subscribers of the list.

Read more on the processing pipeline in the overview deepdive.

Egress​

The place where emails leave the pipeline to be send out to subscribers and end up in inboxes. The egress provider manages everything that is needed to ensure deliverability and notifies our server of bounces and other real-world failiure cases.

Supported sinks​

We currently support two egress providers on a first-party basis:

You need one of them to be up and running correctly if you want MailFlow Relay to be able to speak with the outside world.

warning

You can only use a single egress providers at one time. An email will only be send once to avoid duplicates unless an error occurs. you can select wich provider you want to use in the instance configuration.

Which provider to use​

Picking a source depends on your requirements, your technical ability and existing infrastructure.

AWS​

This type requires basic knowlege of AWS to set up and a few settings to avoid unexpected costs. For low-volume usecases under 2.000 mails/month without gigantic attachments it can be significantly cheaper and easier then managing your own mailserver. You can also host the MailFlow Relay software directly on AWS (eg. via EC2).

More on setting up on AWS, a guide, and other information can be found here.

Bring-Your-Own-Server​

If you already have a mailserver setup and running you can get up and forwarding much faster then with AWS. More on how to get started with setting up MailFlow Relay with your existing server and what requirements and features you need to support can be found here.

You can run the MailFlow Relay server software on any Internet-reachable server that can communicate with your chosen ingress and egress provider.

For testing you can even run MailFlow Relay on any laptop or PC via an ngrok tunnel.

Footnotes​

  1. Providers that specialize in just doing one thing well are usually also cheaper on a per-usage basis in money and time then rolling your own just because you could. Also they usually found the edgecases you didnt hit yet already. ↩