[GH-ISSUE #415] [feature-request] Additional hook on incoming email BEFORE processing #270

New issue

Closed

opened 2026-03-15 13:33:21 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 13:33:21 +03:00

Owner

Originally created by @baiomys on GitHub (Dec 31, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/415

Hi, it would be handy to have a possibility of calling a worker to analyze TO, FROM, SIZE (if sent), and make a decision to accept or reject email. This measure can cut about 80% of dumb spam traffic, dramatically reducing VPS load/cost.

Originally created by @baiomys on GitHub (Dec 31, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/415 Hi, it would be handy to have a possibility of calling a worker to analyze TO, FROM, SIZE (if sent), and make a decision to accept or reject email. This measure can cut about 80% of dumb spam traffic, dramatically reducing VPS load/cost.

kerem closed this issue

2026-03-15 13:33:27 +03:00

kerem commented

2026-03-15 13:33:32 +03:00

Author

Owner

@axllent commented on GitHub (Jan 1, 2025):

Hi @baiomys. The SMTP protocol doesn't work in that way - the message needs to be accepted & received before things like the size can be seen. Furthermore, in order to "filter" by TO and FROM during delivery, then Mailpit would need to interact with a third party API as part of the SMTP process, which in itself would be prone to errors if, for instance, Mailpit can't contact the the API, or Mailpit receives 1000 messages in a second.

Mailpit is designed to accept everything provided it is a valid SMTP transaction, with one exception being the --smtp-allowed-recipients / MP_SMTP_ALLOWED_RECIPIENTS option which can be used to limit addresses and domains (using a regular expression, so not complicated, and probably not what you are needing).

If Mailpit is exposed to the internet, then you are going to get spam at some point I'm afraid, just like any open SMTP server. If you are wanting to filter received messages to remove spam, then I think you should be doing things very differently, either:

Your webhook endpoint needs to pull the message and decide whether to "process" (call your Telegram bot) or just delete (or ignore) the message via the API. This allows you to do anything you want, including get the size, from, to, body etc.
You need to create a custom SMTP server that sits between the internet and Mailpit which can authenticate against whatever system you want.

I think that the first option is probably the easiest. It still means the spam message is received in Mailpit, however it is potentially just deleted afterwards by your webhook endpoint / API if it fails the checks.

I am curious as to how receiving 80% more messages is drastically increasing your VPS & load. Is this extra load on the Mailpit side (and if so, how many messages are you handling every hour?), or is this on your bot side?

@axllent commented on GitHub (Jan 1, 2025): Hi @baiomys. The SMTP protocol doesn't work in that way - the message needs to be accepted & received before things like the size can be seen. Furthermore, in order to "filter" by `TO` and `FROM` during delivery, then Mailpit would need to interact with a third party API as part of the SMTP process, which in itself would be prone to errors if, for instance, Mailpit can't contact the the API, or Mailpit receives 1000 messages in a second. Mailpit is designed to accept everything provided it is a valid SMTP transaction, with one exception being the `--smtp-allowed-recipients` / `MP_SMTP_ALLOWED_RECIPIENTS` option which can be used to limit addresses and domains (using a regular expression, so not complicated, and probably not what you are needing). If Mailpit is exposed to the internet, then you are going to get spam at some point I'm afraid, just like any open SMTP server. If you are wanting to filter received messages to remove spam, then I think you should be doing things very differently, either: 1. Your webhook endpoint needs to pull the message and decide whether to "process" (call your Telegram bot) or just delete (or ignore) the message via the API. This allows you to do anything you want, including get the size, from, to, body etc. 2. You need to create a custom SMTP server that sits between the internet and Mailpit which can authenticate against whatever system you want. I think that the first option is probably the easiest. It still means the spam message is received in Mailpit, however it is potentially just deleted afterwards by your webhook endpoint / API if it fails the checks. I am curious as to how receiving 80% more messages is drastically increasing your VPS & load. Is this extra load on the Mailpit side (and if so, how many messages are you handling every hour?), or is this on your bot side?

kerem commented

2026-03-15 13:33:38 +03:00

Author

Owner

@baiomys commented on GitHub (Jan 1, 2025):

Hi, thanks for detailed answer.

It is obvious now that I should use workers on Cloudflare side for basic spam filtering.
At least until I get 100 000 messages a day.

In decentralized system, having dozen of pits around the globe and 4 bots it is impossible to touch any messages by core handler just to check validity. Or you need to be META at least. =)

Core handler even does not upload emails by request itself, just validates credentials and redirects browser to corresponding pit that use fancy Caddy templates to get things running.

Planning must be done VERY CAREFULLY, because reengineering of live project is real pain in the ....

@baiomys commented on GitHub (Jan 1, 2025): Hi, thanks for detailed answer. It is obvious now that I should use workers on Cloudflare side for basic spam filtering. At least until I get 100 000 messages a day. In decentralized system, having dozen of pits around the globe and 4 bots it is impossible to touch any messages by core handler just to check validity. Or you need to be META at least. =) Core handler even does not upload emails by request itself, just validates credentials and redirects browser to corresponding pit that use fancy Caddy templates to get things running. Planning must be done VERY CAREFULLY, because reengineering of live project is real pain in the ....