6 ms·

> I’ve been working on a small side project that involves processing incoming email. In particular, it’s an app that needs to do something for each email it rec

by tuldia 7y ago

> I’ve been working on a small side project that involves processing incoming email. In particular, it’s an app that needs to do something for each email it receives from (hopefully paying!) users. I wish you all the best! Mind if I ask for the link? > With (1), there is no need to worry about overages, but scaling the mail server might be challenging. Honestly, quite the opposite. 1. Duplicate your MX box. 2. Duplicate your MX record. That is it :) > I am writing the mail processing daemon ... in Rust... You might like to take a look in https://github.com/mailman/mailman https://github.com/mailman/mailman for ideas/inspiration. It's a great tool for processing emails too, but cannot deny I'm now curious to see how one in rust will look like.

Cyph0n 7y ago
Thanks! No link yet, but there is a messy GH repo: https://github.com/aksiksi/vaulty https://github.com/aksiksi/vaulty Yes, I only learned about MX record priorities last night haha. With Postfix, the most straightforward way to run code on receiving an email seems to be through a pipe filter. Running multiple filter processes probably requires a beefy server. Thanks for that link! I might just use a similar approach to allow users to configure how to receive emails (HTTP or stdin, etc.).
- tuldia 7y ago
  Thanks for the link! Seems like a really fun project. > I only learned about MX record priorities last night haha. Nice! > With Postfix, the most straightforward way to run code on receiving an email seems to be through a pipe filter. True. Take a look into LMTP, you may be able to "read the email" directly from your rust daemon (via unix socket or tcp) :)
- unilynx 7y ago
  Then limit the number of filters... you can have postfix run a fixed number of smtpd processes, and each process handles only one message at a time. When they're all full, your server will just stop handling messages, but SMTP will retry anyway, giving you plenty of time to scale up if the load is consistently too high

by tuldia 7y ago

Cyph0n 7y ago

Thanks! No link yet, but there is a messy GH repo: https://github.com/aksiksi/vaulty https://github.com/aksiksi/vaulty Yes, I only learned about MX record priorities last night haha. With Postfix, the most straightforward way to run code on receiving an email seems to be through a pipe filter. Running multiple filter processes probably requires a beefy server. Thanks for that link! I might just use a similar approach to allow users to configure how to receive emails (HTTP or stdin, etc.).

tuldia 7y ago
Thanks for the link! Seems like a really fun project. > I only learned about MX record priorities last night haha. Nice! > With Postfix, the most straightforward way to run code on receiving an email seems to be through a pipe filter. True. Take a look into LMTP, you may be able to "read the email" directly from your rust daemon (via unix socket or tcp) :)
unilynx 7y ago
Then limit the number of filters... you can have postfix run a fixed number of smtpd processes, and each process handles only one message at a time. When they're all full, your server will just stop handling messages, but SMTP will retry anyway, giving you plenty of time to scale up if the load is consistently too high