parsemail VS aws-lambda-ses-forwarder

It's a pain in the ass right now. Original I come up with the domain hanami.run because I explained here https://www.youtube.com/watch?v=O1p2crPpFIc I feel like wind blow flowers where Hanami blow out emails.

I run an email forwarding services (https://hanami.run if you want to check it out) and I can share some info:

I found https://hanami.run (soon to be mailwip.com due to name conflict with hanamirb.org) to setup email forwarding and a simple blog platform by "email to post" and webhook.

Use it you can consolidate emails from multiple domains to forward to the same inbox. And you can add webhook/slack notification too.

You can look into mine (https://hanami.run) very fast to sign up and have a few cool features about webhook or smtp.

Also, improvmx.com is a great product as well.

If you like open source, https://maddy.email/ is a single binary deployment that can handle everything even IMAP.

https://mailcow.github.io/mailcow-dockerized-docs/ is a dockerize solution with super detail document as well.

If you want to compete with the big players, you have to solve the most important pain point and work upward from that small use base.

My case: I work on https://hanami.run (will soon move to https://mailwip.com due to hanamirb.org conflict) and email forwarding is very competitive. Big and old players are all over the place because at the end of day, setting up email forwarding isn't hard and many open source project did it, heck you can spin up AWS lambda for incoming email in no time.

The pain point is: email will drop sometime, time to time no matter how good an email forwarding service is because they have to scan spam, have false positive, or because of strict DMARC/SPF rule. And I have no tools available to help me out there. So I focus strongly on my maillog features with many level of privacy:

- no log at all

- docker-compose to spin up everything. It's super nice. Again, the deployment is done with a `rsync` then `docker-compose up -f docker-compose-prod.yml`

Eventually when deployment changes very frequent and need scale/ha I added in Kubernetes. K8S is way easiser to setup than you think and it handle all other suff(load balancer, environment variable etc).

And my deploy now become: `kubectl apply -f`

One trick I used is to use `sed` or `envsubst` to replace the image hash.

For backedup, I again, literally setup cronjob from an external server, `ssh` into database and run `pgdump`.

I also have a nice NFS server to centralize config and sync back to our git repo.

I used this whole setup to operate https://hanami.run an email forwarding service for the first 3 months before I added Kubernetes.

So I want to share a story about user asking for a feature then not using it.

I run an email forwarding services(https://hanami.run) basically you add your domains in and add some records.

We had this one heavy users who has like hundreds of domains. So our UI isn't design for that. Who has hundreds of domains? So they approach and asked us for a way to organize those domains into a hierarchy structure.

All good.

They are paid our highest tier ($30 per month) so we prioritize the requests and work on it.

2 days later that same user downgrade to the lowest plan and delete all of their hundred of domains...

That complicated features remain unused to nowadays...

I used hanami.run and they support that. A catch-all then an explicitly deny rule to disable certain address.

Wix doesn't have built-in email forwarding but you can use any email forwarding service. Look into hanami.run and simply follow their onboarding process to add your MX record. https://hanami.run/docs/configure_dns#mx

If they cannot use cloudflare(since we need to use its nameserver), you can self hosted a tool like https://github.com/arithmetric/aws-lambda-ses-forwarder It's powered by AWS Lambda so work flawlessly.

> Could there be a serverless alternative where the service wakes up only to receive emails and will be charged only when emails are processed, filtered and served & rest of the time no charge - avoiding $3 to $5 charged by behemoths per inbox?

I love ideas as much as the next guy and serverless email is kind of floating out there:

https://medium.com/schibsted-engineering/building-a-serverle...

https://github.com/arithmetric/aws-lambda-ses-forwarder

https://github.com/0x4447/0x4447_product_s3_email

It's possible to build it, but the problem is that you still have the same problem of deliverability. Obviously it works fine/great for receving emails though.

> Idea is how cheap can it go for personal inbox with all the features denied by the superlative pricing plans

It could get really cheap, but would people buy it? I always wonder if price is really the limiting factor for self hosted emails.

Zoho is already QUITE cheap: https://www.zoho.com/mail/zohomail-pricing.html

Maybe this would work as a business, but it's a bit questionable to me.

When using SES, you cannot set FROM header to anything. The FROM has to be either an whitelisted email address or a domain that you own and verified with SES.

When forwarding email, we are receiving email from unknow domains. If we rewrite the FROM headers then the DKIM will invalid, so service will have to rewrite the FROM and clear out DKIM.

This is a well-known SES issue and project has to work around https://github.com/arithmetric/aws-lambda-ses-forwarder

```

If you are willing to mess around with code https://github.com/arithmetric/aws-lambda-ses-forwarder use this. It's essentially use AWS SES to process inbound email and lambda to forward email out.

It is unmaintained https://github.com/arithmetric/aws-lambda-ses-forwarder/issues/119 and written in godawful JS promise syntax. So while it may work, I didn't feel like trying it.

Thanks to Joe Turgeon for inspiration of the tutorial: https://github.com/arithmetric/aws-lambda-ses-forwarder