[GH-ISSUE #492] Add switch to modify behavior for not accepting mails #316

Closed
opened 2026-03-15 13:51:07 +03:00 by kerem · 8 comments
Owner

Originally created by @gliwka on GitHub (May 9, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/492

We use mailpit in a test environment and have a restriction on the domain for which mailpit accepts emails (--smtp-allowed-recipients).

Some standard-software and custom developed software is not too happy with receiving a "550 5.1.0 Requested action not taken: mailbox unavailable" if the address is not on the allowlist.

Those software packages expect a forwarding relay on the other end that simply takes all emails and returns a 2xx and then forwards the mails asynchronously (and potentially fails then).

Would you be willing to accept a PR for a switch that enables for mails to be just accepted with a 2xx code and then dropped silently instead of receiving a 550?

Originally created by @gliwka on GitHub (May 9, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/492 We use mailpit in a test environment and have a restriction on the domain for which mailpit accepts emails (--smtp-allowed-recipients). Some standard-software and custom developed software is not too happy with receiving a "550 5.1.0 Requested action not taken: mailbox unavailable" if the address is not on the allowlist. Those software packages expect a forwarding relay on the other end that simply takes all emails and returns a 2xx and then forwards the mails asynchronously (and potentially fails then). Would you be willing to accept a PR for a switch that enables for mails to be just accepted with a 2xx code and then dropped silently instead of receiving a 550?
kerem 2026-03-15 13:51:07 +03:00
  • closed this issue
  • added the
    stale
    label
Author
Owner

@axllent commented on GitHub (May 9, 2025):

Hi @gliwka. If I understand you correctly, you effectively want a new feature with something like --smtp-drop-rejected-recipients to effectively accept the email and then just delete it? I'm not sure that's the best flag name due to the length of it, but you may have a better suggestion.

Assuming I am correct, I'm not sure this is possible, at least not easily and not without rewriting how the smtpd library works. I haven't looked too deep into it, but from what I can see the smtpd uses a handlerRcpt() function which returns a bool, and this function determines whether the SMTPAllowedRecipientsRegexp (the compiled regular expression based on the --smtp-allowed-recipients flag) exists and matches the address.

I think this could be a useful addition to Mailpit, so I would be willing to consider a PR for this if you are able to find an elegant way to integrate this in a matter that does not require a major hack to the smtpd library. The upside is that the smtpd library is included in Mailpit (not a third-party library any more as I needed to make some other minor changes in the past), however I would prefer not to fill it with hacks or completely change how it works. You may think of a better approach though if you're keen on looking into that further.

There are additional complications though which you should be aware of and which need to be considered, for instance auto-relaying & auto-forwarding of messages which obviously should not be run on ignored messages either. Most of the core functionality you would be looking at would be found in internal/smtpd/main.go and internal/smtpd/smtd.go.

<!-- gh-comment-id:2866055535 --> @axllent commented on GitHub (May 9, 2025): Hi @gliwka. If I understand you correctly, you effectively want a new feature with something like `--smtp-drop-rejected-recipients` to effectively accept the email and then just delete it? I'm not sure that's the best flag name due to the length of it, but you may have a better suggestion. Assuming I am correct, I'm not sure this is possible, at least not easily and not without rewriting how the smtpd library works. I haven't looked too deep into it, but from what I can see the smtpd uses a `handlerRcpt()` function which returns a bool, and this function determines whether the `SMTPAllowedRecipientsRegexp` (the compiled regular expression based on the `--smtp-allowed-recipients` flag) exists and matches the address. I think this could be a useful addition to Mailpit, so I would be willing to **consider** a PR for this if you are able to find an elegant way to integrate this in a matter that does not require a major hack to the smtpd library. The upside is that the smtpd library is included in Mailpit (not a third-party library any more as I needed to make some other minor changes in the past), however I would prefer not to fill it with hacks or completely change how it works. You may think of a better approach though if you're keen on looking into that further. There are additional complications though which you should be aware of and which need to be considered, for instance auto-relaying & auto-forwarding of messages which obviously should not be run on ignored messages either. Most of the core functionality you would be looking at would be found in `internal/smtpd/main.go` and `internal/smtpd/smtd.go`.
Author
Owner

@gliwka commented on GitHub (May 12, 2025):

Thank you for the pointers. Yes, I propose to introduce the functionality with a few isolated changes to the main loop of smtpd:

I will open a PR with those changes and the neccesary covering tests.

All the relaying, forwarding and saving etc. happens in the handlers, so it will be enough to just not execute them if accepted is not "true".

<!-- gh-comment-id:2871685924 --> @gliwka commented on GitHub (May 12, 2025): Thank you for the pointers. Yes, I propose to introduce the functionality with a few isolated changes to the main loop of smtpd: - Introduce the command line param (--smtp-drop-rejected-recipients) - Give the smtp server struct that param as boolean (SilentlyDropRejectedRecipients) - After the call of HandlerRcpt, short-circuit the evaluation of the accepted flag if SilentlyDropRejectedRecipients is set (https://github.com/axllent/mailpit/blob/009f3a8fd967cbbebbafdf5478eade0320756ecd/internal/smtpd/smtpd.go#L489) - Add checks for the accepted flag before the handler gets called, so the logic falls through into the last case which doesn't call the handler and just prints `250 Queued` https://github.com/axllent/mailpit/blob/009f3a8fd967cbbebbafdf5478eade0320756ecd/internal/smtpd/smtpd.go#L540 https://github.com/axllent/mailpit/blob/009f3a8fd967cbbebbafdf5478eade0320756ecd/internal/smtpd/smtpd.go#L552 - Add logging to that else case to make it clear that the handler has been skipped https://github.com/axllent/mailpit/blob/009f3a8fd967cbbebbafdf5478eade0320756ecd/internal/smtpd/smtpd.go#L570 I will open a PR with those changes and the neccesary covering tests. All the relaying, forwarding and saving etc. happens in the handlers, so it will be enough to just not execute them if accepted is not "true".
Author
Owner

@github-actions[bot] commented on GitHub (May 20, 2025):

This issue has been marked as stale because it has been open for 7 days with no activity.

<!-- gh-comment-id:2892705035 --> @github-actions[bot] commented on GitHub (May 20, 2025): This issue has been marked as stale because it has been open for 7 days with no activity.
Author
Owner

@gliwka commented on GitHub (May 23, 2025):

PR will open this week, got busy, but we still need this.

<!-- gh-comment-id:2903617242 --> @gliwka commented on GitHub (May 23, 2025): PR will open this week, got busy, but we still need this.
Author
Owner

@github-actions[bot] commented on GitHub (May 31, 2025):

This issue has been marked as stale because it has been open for 7 days with no activity.

<!-- gh-comment-id:2923990044 --> @github-actions[bot] commented on GitHub (May 31, 2025): This issue has been marked as stale because it has been open for 7 days with no activity.
Author
Owner

@github-actions[bot] commented on GitHub (Jun 3, 2025):

This issue was closed because there has been no activity since being marked as stale.

<!-- gh-comment-id:2933122305 --> @github-actions[bot] commented on GitHub (Jun 3, 2025): This issue was closed because there has been no activity since being marked as stale.
Author
Owner

@gliwka commented on GitHub (Aug 5, 2025):

Finally got around to implementing it here: https://github.com/axllent/mailpit/pull/549

<!-- gh-comment-id:3155891643 --> @gliwka commented on GitHub (Aug 5, 2025): Finally got around to implementing it here: https://github.com/axllent/mailpit/pull/549
Author
Owner

@axllent commented on GitHub (Aug 10, 2025):

Released in v1.24.7.

<!-- gh-comment-id:3172501057 --> @axllent commented on GitHub (Aug 10, 2025): Released in [v1.24.7](https://github.com/axllent/mailpit/releases/tag/v1.27.4).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mailpit#316
No description provided.