aksiksi
commented
4 years ago How about keeping the filter process minimal? Two options:
Option 1
Write mail to RabbitMQ instance. A second process watches the queue and handles any incoming requests.
- Downsides: additional software
- Upsides: performance?
Option 2
HTTP POST to vaulty_server running on the same machine. Headers for sender, recipient, and any other relevant email data; body contains actual attachments (JSON list?). Server then does the DB lookup and writes everything to storage via vaulty_lib.
- Downside: performance
- Upside: easier to maintain, expandable to other mail services.
Regarding the upside, the same server can be deployed for scenarios where we instead opt to use an API like Mailgun.
In either case, vaulty_filter will simply:
- Receive mail via stdin
- Parse mail to extract relevant fields
- Perform DB lookup to check if recipient address has whitelist enabled
- If whitelist enabled, silently drop message and post to stats table
- Serialize attachments from MIME into JSON
- Send off to either server or RMQ instance
No async required. Minimal dependencies. Minimal allocations. Optimized for single threaded perf.
Note that Postfix will use DB lookup to determine valid recipient mailboxes. So the filter will only be triggered for valid recipient addresses. The filter will not validate sender; this is left to the server to handle. In other words, Postfix will not bounce any mail to valid recipients. User will be notified via dashboard or email API service.
With the recent Mailgun price increase announcement, it makes sense to roll a custom Postfix server for receiving mail.
Note that, since we will be primarily receiving mail, deliverability will not be much of an issue. For signup and payment flows, we can decide to use an API if it makes sense.
PRs