starred/mailpit

Fork 0

mirror of https://github.com/axllent/mailpit.git synced 2026-04-26 00:35:51 +03:00

[GH-ISSUE #108] Allowlist recipients #72

New issue

Closed

opened 2026-03-15 12:23:36 +03:00 by kerem · 9 comments

kerem commented

2026-03-15 12:23:36 +03:00

Owner

Originally created by @gliwka on GitHub (May 4, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/108

I would like to restrict the possible email recipients of the SMTP relay feature, i.e. using regex to match certain domains. Only mails matching the allowlist can be relayed.

@axllent Would this be something you‘d accept a pull request for?

Implementation wise I could filter out all recipients not matching the regex in the send function and just return, if the list is empty after that: github.com/axllent/mailpit@f2bce03e9e/server/smtpd/smtp.go (L12)

I would add a new field to the existing relay config allowing users to specify the regex used to whitelist recipients.

Originally created by @gliwka on GitHub (May 4, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/108 I would like to restrict the possible email recipients of the SMTP relay feature, i.e. using regex to match certain domains. Only mails matching the allowlist can be relayed. @axllent Would this be something you‘d accept a pull request for? Implementation wise I could filter out all recipients not matching the regex in the send function and just return, if the list is empty after that: https://github.com/axllent/mailpit/blob/f2bce03e9e57a32b7aa83c815e540fe2d112075a/server/smtpd/smtp.go#L12 I would add a new field to the existing relay config allowing users to specify the regex used to whitelist recipients.

kerem closed this issue

2026-03-15 12:23:41 +03:00

kerem commented

2026-03-15 12:23:47 +03:00

Author

Owner

@axllent commented on GitHub (May 4, 2023):

@gliwka Definitely interested. Ideally there would be some frontend message to tell the user the email(s) is invalid, so maybe the detection logic is better placed in the API route as this would apply to manually released messages only. The reason is that the other use of the Send() is used via --smtp-relay-all (which implies that ALL emails should be auto-forwarded).

@axllent commented on GitHub (May 4, 2023): @gliwka Definitely interested. Ideally there would be some frontend message to tell the user the email(s) is invalid, so maybe the detection logic is better placed in the API route as this would apply to manually released messages only. The reason is that the other use of the `Send()` is used via `--smtp-relay-all` (which implies that ALL emails should be auto-forwarded).

kerem commented

2026-03-15 12:23:52 +03:00

Author

Owner

@gliwka commented on GitHub (May 4, 2023):

@axllent Makes sense, will look into how to provide feedback to the user in the API handler as well. I can also add the whitelist regex to the webgui handler, so I can display it to the user in the MessageRelease modal similar to the return path.

Would it be fine to add a --smtp-relay-whitelist as well? I have the need to restrict it both for the manual release, as well as the auto-forwarding.

@gliwka commented on GitHub (May 4, 2023): @axllent Makes sense, will look into how to provide feedback to the user in the API handler as well. I can also add the whitelist regex to the webgui handler, so I can display it to the user in the MessageRelease modal similar to the return path. Would it be fine to add a --smtp-relay-whitelist as well? I have the need to restrict it both for the manual release, as well as the auto-forwarding.

kerem commented

2026-03-15 12:23:57 +03:00

Author

Owner

@axllent commented on GitHub (May 4, 2023):

Good point. Hmm, I haven't had enough coffee yet to think this one properly through 😂 I actually take back my previous comment - I think that if whitelisting is enabled, it should apply to both the manually and auto-forwarded messages, and not overcomplicate things by having two separate flags, at least not at this stage.

So ideally:

auto-forwarding silents drops addresses not matching the whitelist (logged in debug), and sending all other matching addresses (if any). A disallowed address should not block any others from being sent.
API / frontend will not allow any sending the address list contains invalid addresses, and return an error if any addresses are not allowed
Frontend would ideally warn beforehand when entering the address (it sounds like you have some ideas)

For starters I would focus on the yaml settings only, not a cli flag, and we could always introduce that down the track if needed.

Does this make sense to you too?

@axllent commented on GitHub (May 4, 2023): Good point. Hmm, I haven't had enough coffee yet to think this one properly through 😂 I actually take back my previous comment - I think that if whitelisting is enabled, it should apply to both the manually and auto-forwarded messages, and not overcomplicate things by having two separate flags, at least not at this stage. So ideally: - auto-forwarding silents drops addresses not matching the whitelist (logged in debug), and sending all other matching addresses (if any). A disallowed address should not block any others from being sent. - API / frontend will not allow any sending the address list contains invalid addresses, and return an error if any addresses are not allowed - Frontend would ideally warn beforehand when entering the address (it sounds like you have some ideas) For starters I would focus on the yaml settings only, not a cli flag, and we could always introduce that down the track if needed. Does this make sense to you too?

kerem commented

2026-03-15 12:24:02 +03:00

Author

Owner

@gliwka commented on GitHub (May 4, 2023):

Awesome, that sounds exactly like what I have on my local branch. Will open a PR later.

@gliwka commented on GitHub (May 4, 2023): Awesome, that sounds exactly like what I have on my local branch. Will open a PR later.

kerem commented

2026-03-15 12:24:07 +03:00

Author

Owner

@axllent commented on GitHub (May 5, 2023):

@gliwka Thanks again for all your hard work and your PR! This feature has been released in v1.6.7.

@axllent commented on GitHub (May 5, 2023): @gliwka Thanks again for all your hard work and your PR! This feature has been released in v1.6.7.

kerem commented

2026-03-15 12:24:12 +03:00

Author

Owner

@gliwka commented on GitHub (May 5, 2023):

@axllent Awesome, thanks so much :-)
Minor correction: seems the version it was released in is v1.6.8

@gliwka commented on GitHub (May 5, 2023): @axllent Awesome, thanks so much :-) Minor correction: seems the version it was released in is v1.6.8

kerem commented

2026-03-15 12:24:17 +03:00

Author

Owner

@axllent commented on GitHub (May 5, 2023):

🤦‍♂️ You're totally right, typo!

@axllent commented on GitHub (May 5, 2023): :man_facepalming: You're totally right, typo!

kerem commented

2026-03-15 12:24:22 +03:00

Author

Owner

@zmweske commented on GitHub (Jul 5, 2024):

Would you consider creating a blocklist as well? I can look at setting up a dev environment but seeing as it is the inverse of a allowlist, it shouldn't be much work maybe? I think that one simple reason for this would be to block all emails sent to admin@admin.lan for some services so they don't spam a downstream SMTP provider (and prevent spam filtering).

@zmweske commented on GitHub (Jul 5, 2024): Would you consider creating a blocklist as well? I can look at setting up a dev environment but seeing as it is the inverse of a allowlist, it shouldn't be much work maybe? I think that one simple reason for this would be to block all emails sent to admin@admin.lan for some services so they don't spam a downstream SMTP provider (and prevent spam filtering).

kerem commented

2026-03-15 12:24:27 +03:00

Author

Owner

@axllent commented on GitHub (Jul 6, 2024):

@zmweske I believe what you are looking for is almost the opposite of --smtp-relay-matching (docs)? I'm not sure that would work though from a configuration perspective, for example if a user specifies just this new flag, does that imply to relay all non-matching emails should be sent, or if the same match is found on both the --smtp-relay-matching and this new flag. This will need a lot of thought as it gets really complicated, but before I do, please open a new issue, as requesting this in a 14 month old closed issue will likely mean it gets forgotten about, thanks 👍

@axllent commented on GitHub (Jul 6, 2024): @zmweske I believe what you are looking for is almost the opposite of `--smtp-relay-matching` ([docs](https://mailpit.axllent.org/docs/configuration/smtp-relay/#automatically-relay-some-messages))? I'm not sure that would work though from a configuration perspective, for example if a user specifies just this new flag, does that imply to relay all non-matching emails should be sent, or if the same match is found on both the `--smtp-relay-matching` and this new flag. This will need a lot of thought as it gets really complicated, but before I do, please open a new issue, as requesting this in a 14 month old closed issue will likely mean it gets forgotten about, thanks :+1:

kerem referenced this issue

2026-03-15 12:56:28 +03:00

[GH-ISSUE #249] Suggestion: IMAP/POP server #165