mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #594] Default mail address when releasing message #382
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#382
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gabriele-v on GitHub (Dec 12, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/594
Hello,
in my use case I'm using mailpit in dev environment just changing the app SMTP configuration from production one, so mail recipients are real addresses that I don't want to send mails when debugging.
I need to release mails to my mailbox to double check the result, so basically every time I need to override the mail address inserted into release function. It would be helpful to have it automatically populated.
I'll leave it up to you to choose the best approach, taking into account any other scenarios you may be aware of.
Personally, the following come to mind:
Thank you very much for the platform, it's really useful and almost perfect!
@axllent commented on GitHub (Dec 12, 2025):
Hi @gabriele-v . I believe the functionality you are describing already exists - by using forwarding instead of releasing.
@gabriele-v commented on GitHub (Dec 12, 2025):
Not really, because forwarding is forwarding all of them. I'd like to release only someones, when everything looks ok.
@axllent commented on GitHub (Dec 12, 2025):
OK, I understand your use-case better. I won't make this a global setting (ie: env or flag), but this could definitely be a browser setting, such as an option to "Save send to" with a "Click to apply" ... or something... in the release modal. I will need to give this a lot more thought as the UI/UX needs to make sense to everyone. If you have suggestions of how the UI could work I'll gladly take that into consideration.
@gabriele-v commented on GitHub (Dec 13, 2025):
Maybe adding another checkbox option here "Save as default releasing addresses".
When enabled and release is clicked, for next releases addresses are automatically inserted into "Send to" and checkbox is enabled. If checkbox is then disabled, it reverts to the original behaviour.
@axllent commented on GitHub (Dec 14, 2025):
Thanks for the suggestion, I'll definitely look at this some time over the next few weeks - sorry, I'm really busy at the moment with end-of-year work commitments.
@gabriele-v commented on GitHub (Dec 14, 2025):
No worries, not urgent on my side, I'll just type my mail more times :)
@iamgerwin commented on GitHub (Dec 18, 2025):
Hi @gabriele-v,
Thank you for the feature request! This is indeed a useful enhancement for development workflows.
I've submitted PR #595 that implements a new configuration option to address this use case. The solution adds:
New Configuration Options:
MP_SMTP_RELAY_DEFAULT_RELEASE_TOdefault-release-toHow it works:
Example usage:
Or in your relay YAML configuration:
This approach follows the existing configuration patterns in Mailpit and integrates seamlessly with the current relay settings.
Looking forward to the maintainer's review!
@gabriele-v commented on GitHub (Dec 18, 2025):
Hi @iamgerwin thanks for the PR.
I don't think that's exactly how @axllent was discussing before, but let's see what he thinks about.
@axllent commented on GitHub (Dec 18, 2025):
Thanks guys. Whilst @gabriele-v is correct (that wasn't my suggested approach), I'll definitely take a look at what @iamgerwin has submitted. I'm currently finishing up for a very busy work year, but I will find time in the next week or two to look into this and provide feedback (if necessary).
@axllent commented on GitHub (Jan 7, 2026):
Sorry about the delay here - I have not forgotten about this feature, I just got caught up in a security issue which required my attention and time. I have started looking into this today and how to have something out by the end of the week.
@axllent commented on GitHub (Jan 10, 2026):
I've released v1.28.2 which includes this new feature. The default release email (or emails) can be set/edited in the web UI settings.
@gabriele-v commented on GitHub (Jan 10, 2026):
Hello, I confirm is working as expected, thank you!
Just for information I've found a small bug, don't know if it can be fixed or a note about that may be added in "Message Release" tab
How to reproduce:
Also in this case is not applied:
@axllent commented on GitHub (Jan 10, 2026):
Hi @gabriele-v - thanks for the feedback, and great to hear it's working well!
I am aware of the glitch you describe - I just wasn't able to find an elegant solution prior to the release as my primary focus was on the two recent security-related fixes. I have just pushed a fix for this issue which will be included in the next release, however given that I have just released two new versions in the last week, it will need to wait until next weekend at the earliest.