[GH-ISSUE #194] Feature request: Reset message date on release

kerem commented

2026-03-15 12:45:25 +03:00

Owner

Originally created by @Leobaillard on GitHub (Oct 17, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/194

Hi!

I'm migrating from Mailhog to Mailpit and I have a usecase where I'd need to store the emails in Mailpit until a specific time where I would need to release them (all at once or one by one with a loop, it does not matter). This behaviour would need to be automated through a CRON job and thus would not work with the UI which is why an API endpoint would be ideal.

Could such API endpoint be implemented? For instance at the message level like /api/v1/message/<ID>/release?

Thanks!

Originally created by @Leobaillard on GitHub (Oct 17, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/194 Hi! I'm migrating from Mailhog to Mailpit and I have a usecase where I'd need to store the emails in Mailpit until a specific time where I would need to release them (all at once or one by one with a loop, it does not matter). This behaviour would need to be automated through a CRON job and thus would not work with the UI which is why an API endpoint would be ideal. Could such API endpoint be implemented? For instance at the message level like `/api/v1/message/<ID>/release`? Thanks!

kerem

2026-03-15 12:45:25 +03:00

closed this issue
added the
enhancement
label

kerem commented

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

Author

Owner

@axllent commented on GitHub (Oct 17, 2023):

Hi. This already exists in the API. See the embedded API documentation (depending on your Mailpit server's URL) on http://localhost:8025/api/v1/#post-/api/v1/message/-ID-/release

The request must be a application/json POST to /api/v1/message/{ID}/release with all the recipients of the release in to (ie: who do you want to relay it to):

{
  "to": [
    "user1@example.com",
    "user2@example.com"
  ]
}

Obviously you must have relaying configured/enabled for this to work. You would probably first require a call to /api/v1/message/{ID} to get a list of the original recipients as the release will not just include everyone automatically (you have to specify each one). See the wiki for more information.

Hope this helps ;-)

@axllent commented on GitHub (Oct 17, 2023): Hi. This already exists in the API. See the embedded API documentation (depending on your Mailpit server's URL) on http://localhost:8025/api/v1/#post-/api/v1/message/-ID-/release The request must be a `application/json` POST to `/api/v1/message/{ID}/release` with all the recipients of the release in `to` (ie: who do you want to relay it to): ```json { "to": [ "user1@example.com", "user2@example.com" ] } ``` Obviously you must have relaying configured/enabled for this to work. You would probably first require a call to `/api/v1/message/{ID}` to get a list of the original recipients as the release will not just include everyone automatically (you have to specify each one). See [the wiki](https://github.com/axllent/mailpit/wiki/SMTP-relay) for more information. Hope this helps ;-)

kerem commented

2026-03-15 12:45:46 +03:00

Author

Owner

@Leobaillard commented on GitHub (Oct 17, 2023):

Oh, nice! I thought it was not implemented as it's not in the API doc but I did not think of checking the actual code, sorry! Would it be possible to add an option/mode to release the message for the recipients (To, Cc, Bcc) specified in the original message?

Also, I assume from your example that the post data can contain "cc" and "bcc" keys, or do they all need to be in "to"?

@Leobaillard commented on GitHub (Oct 17, 2023): Oh, nice! I thought it was not implemented as it's not in the API doc but I did not think of checking the actual code, sorry! Would it be possible to add an option/mode to release the message for the recipients (To, Cc, Bcc) specified in the original message? Also, I assume from your example that the post data can contain "cc" and "bcc" keys, or do they all need to be in "to"?

kerem commented

2026-03-15 12:45:51 +03:00

Author

Owner

@axllent commented on GitHub (Oct 17, 2023):

The requirement to specify all addresses manually was intentional to protect users from accidental spam / mail bombs, so I don't plan on this without good cause. You can easily get the full list of the original recipients as I pointed out earlier.

All addresses (that you wish to relay to) go in the to field. This won't reformat your email, it just tells the relay SMTP to whom the email should be sent to.

Most people don't realise this, but an SMTP server does not scan the message headers to find out who it should go to, it is actually told who it goes to by the SMTP client (or relating SMTP server), so they are not actually linked.

@axllent commented on GitHub (Oct 17, 2023): The requirement to specify all addresses manually was intentional to protect users from accidental spam / mail bombs, so I don't plan on this without good cause. You can easily get the full list of the original recipients as I pointed out earlier. All addresses (that you wish to relay to) go in the `to` field. This won't reformat your email, it just tells the relay SMTP to whom the email should be sent to. Most people don't realise this, but an SMTP server does not scan the message headers to find out who it should go to, it is actually told who it goes to by the SMTP client (or relating SMTP server), so they are not actually linked.

kerem commented

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

Author

Owner

@Leobaillard commented on GitHub (Oct 17, 2023):

Thanks for the clear explanation!

One final ask: I can see that the original date/time of the message is kept when releasing it. Any chance the date/time could be rewritten to the actual release date/time?

@Leobaillard commented on GitHub (Oct 17, 2023): Thanks for the clear explanation! One final ask: I can see that the original date/time of the message is kept when releasing it. Any chance the date/time could be rewritten to the actual release date/time?

kerem commented

2026-03-15 12:46:01 +03:00

Author

Owner

@axllent commented on GitHub (Oct 17, 2023):

This could probably be added, I'd need to first consider what the implications of that are. Can you please explain how you are using this to give me a better idea of why this is necessary?

@axllent commented on GitHub (Oct 17, 2023): This could probably be added, I'd need to first consider what the implications of that are. Can you please explain how you are using this to give me a better idea of why this is necessary?

kerem commented

2026-03-15 12:46:06 +03:00

Author

Owner

@Leobaillard commented on GitHub (Oct 17, 2023):

I have an internal ERP that sends emails for invoices, HR stuff and quotes but I'd like all the emails sent from the ERP to be released at midnight. I wanted to use a solution that provided a UI like Mailpit so that certain emails could be viewed before actually being sent out and to have the ability to remove some if they are not correct.

The idea was to use Mailpit as the configured mail target for the ERP and then have a script executed by a CRON job at midnight that would release all available messages. The messages would need to have the actual send time in their headers so that the feeling of an "automated" sending of emails is maintained. I would do all of this in the ERP, but it does not include these features.

@Leobaillard commented on GitHub (Oct 17, 2023): I have an internal ERP that sends emails for invoices, HR stuff and quotes but I'd like all the emails sent from the ERP to be released at midnight. I wanted to use a solution that provided a UI like Mailpit so that certain emails could be viewed before actually being sent out and to have the ability to remove some if they are not correct. The idea was to use Mailpit as the configured mail target for the ERP and then have a script executed by a CRON job at midnight that would release all available messages. The messages would need to have the actual send time in their headers so that the feeling of an "automated" sending of emails is maintained. I would do all of this in the ERP, but it does not include these features.

kerem commented

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

Author

Owner

@axllent commented on GitHub (Oct 17, 2023):

Thanks for the information, makes sense to me. Interesting use case though....

Just for the record, in order to update the Date header, the old one would be removed and replaced with a new one. This does not remove any other existing headers though, so there is still technical information within the headers (Received etc) that would contradict the new Date, however email clients will just look at the Date which is the one displayed in the client. I don't believe this will impact spam filters, but mileage may vary. I need to try and test before I can assess the impact, and ultimately decide on this feature.

I'll keep you posted on this.

@axllent commented on GitHub (Oct 17, 2023): Thanks for the information, makes sense to me. Interesting use case though.... Just for the record, in order to update the `Date` header, the old one would be removed and replaced with a new one. This does not remove any other existing headers though, so there is still technical information within the headers (`Received` etc) that would contradict the new Date, however email clients will just look at the Date which is the one displayed in the client. I don't believe this will impact spam filters, but mileage may vary. I need to try and test before I can assess the impact, and ultimately decide on this feature. I'll keep you posted on this.

kerem commented

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

Author

Owner

@Leobaillard commented on GitHub (Oct 17, 2023):

Thanks a lot for considering this! Should I close this issue and open a new one or is it not necessary?

@Leobaillard commented on GitHub (Oct 17, 2023): Thanks a lot for considering this! Should I close this issue and open a new one or is it not necessary?

kerem commented

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

Author

Owner

@axllent commented on GitHub (Oct 17, 2023):

Please leave this one open, no need for a new one 👍

@axllent commented on GitHub (Oct 17, 2023): Please leave this one open, no need for a new one 👍

kerem commented

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

Author

Owner

@axllent commented on GitHub (Oct 18, 2023):

Just to keep you in the loop. I have done some experimenting and this appears to work as expected, and releasing the message to a Gmail-hosted email domain didn't trigger any alarms either (in my opinion Gmail has one of the best spam filtering systems). It's always difficult to tell though as spam filters are dependent now on so many factors. The emails arrive with the "current" date displaying (ie; the new one in the Date: header) - even though they were originally dated from days ago. Previously these would arrive with the original message date/time, in the same manner a message may be temporarily "stuck" due to routing or mail issues. As an "added bonus", I am now replacing the date value, rather than deleting the old and injecting the new at the top of the headers as I was concerned about the spam filters (still not sure if that matters, either now or potentially in the future).

There is something you must always consider before implementing this (given your use case): is the configured relay SMTP server authorised to send email on behalf of your domain (ie: those being generated in via your ERP)? I suspect it will be following a similar path to what previous emails were using (when sent directly), but it's worth remembering if you are now routing the relayed mails via a new SMTP server. This has caught me out several times in the past, as I artificially inject my entire mail database into Mailpit for testing, and releasing something that (for instance) originally came from a @gmail.com address gets rejected as my SMTP IP is not authorised to send those :)

Another thing to note is that the original Message ID is always overwritten when relaying - so if somebody replied to a message then your end may not be able to group/thread that reply correctly. This is not a new feature in Mailpit, as email systems like Gmail ignore "duplicate" messages when a message with the same ID already exists. This was implemented to prevent any confusion as to why messages maybe weren't being received (or why just the first release worked but any subsequent one didn't).

I still have a bit more testing to do, but I expect this to be released in the next few days.

@axllent commented on GitHub (Oct 18, 2023): Just to keep you in the loop. I have done some experimenting and this appears to work as expected, and releasing the message to a Gmail-hosted email domain didn't trigger any alarms either (in my opinion Gmail has one of the best spam filtering systems). It's always difficult to tell though as spam filters are dependent now on so many factors. The emails arrive with the "current" date displaying (ie; the new one in the `Date:` header) - even though they were originally dated from days ago. Previously these would arrive with the original message date/time, in the same manner a message may be temporarily "stuck" due to routing or mail issues. As an "added bonus", I am now replacing the date value, rather than deleting the old and injecting the new at the top of the headers as I was concerned about the spam filters (still not sure if that matters, either now or potentially in the future). There is something you must always consider before implementing this (given your use case): is the configured relay SMTP server authorised to send email on behalf of your domain (ie: those being generated in via your ERP)? I suspect it will be following a similar path to what previous emails were using (when sent directly), but it's worth remembering if you are now routing the relayed mails via a new SMTP server. This has caught me out several times in the past, as I artificially inject my entire mail database into Mailpit for testing, and releasing something that (for instance) originally came from a @gmail.com address gets rejected as my SMTP IP is not authorised to send those :) Another thing to note is that the original Message ID is always overwritten when relaying - so if somebody replied to a message then your end may not be able to group/thread that reply correctly. This is not a new feature in Mailpit, as email systems like Gmail ignore "duplicate" messages when a message with the same ID already exists. This was implemented to prevent any confusion as to why messages maybe weren't being received (or why just the first release worked but any subsequent one didn't). I still have a bit more testing to do, but I expect this to be released in the next few days.

kerem commented

2026-03-15 12:46:32 +03:00

Author

Owner

@Leobaillard commented on GitHub (Oct 18, 2023):

Thank you so much for your tests and for taking this into account!

I have one more piece of info that could be useful. I don't have extensive data on this yet (I only implemented the solution yesterday, using the current version and waiting to see what would happen at midnight): 3 emails were waiting in Mailpit and my Python script calling the API was successfully executed at midnight.

During my tests yesterday, I was releasing emails sent only minutes prior and the time showed in Gmail (for my tests I was doing: ERP -> Mailpit -> Brevo (Sendinblue) -> Gmail) was the original one and not the time when the email was released, which prompted my request here. However, the real emails queued yesterday (1 around 2PM and 2 around 6PM) and released at midnight were showing "00:00" as their received time in Gmail, contrasting with what I was experiencing earlier 🤔

My assumption is that maybe there is a limit allowed for bounces and retries and passing that limit, the actual sending date is displayed rather that the creation date of the message (at least in Gmail, I haven't tested other clients)?

IMO this does not render the request made here useless, it's just something to be considered. And again, I have only one execution of historical data, so mileage may vary!

@Leobaillard commented on GitHub (Oct 18, 2023): Thank you so much for your tests and for taking this into account! I have one more piece of info that could be useful. I don't have extensive data on this yet (I only implemented the solution yesterday, using the current version and waiting to see what would happen at midnight): 3 emails were waiting in Mailpit and my Python script calling the API was successfully executed at midnight. During my tests yesterday, I was releasing emails sent only minutes prior and the time showed in Gmail (for my tests I was doing: ERP -> Mailpit -> Brevo (Sendinblue) -> Gmail) was the original one and not the time when the email was released, which prompted my request here. However, the real emails queued yesterday (1 around 2PM and 2 around 6PM) and released at midnight were showing "00:00" as their received time in Gmail, contrasting with what I was experiencing earlier :thinking: My assumption is that maybe there is a limit allowed for bounces and retries and passing that limit, the actual sending date is displayed rather that the creation date of the message (at least in Gmail, I haven't tested other clients)? IMO this does not render the request made here useless, it's just something to be considered. And again, I have only one execution of historical data, so mileage may vary!

kerem commented

2026-03-15 12:46:37 +03:00

Author

Owner

@axllent commented on GitHub (Oct 18, 2023):

Thanks for the feedback. I'm not sure exactly how the inner workings of Gmail work, and what/how they base their received dates, but I'm pretty sure the latest change (I referred to earlier) will ensure it's more consistent - at least I hope that's the case. Time will tell (no pun intended) :) Glad to hear your API execution is working as expected too.

@axllent commented on GitHub (Oct 18, 2023): Thanks for the feedback. I'm not sure exactly how the inner workings of Gmail work, and what/how they base their received dates, but I'm pretty sure the latest change (I referred to earlier) will ensure it's more consistent - at least I hope that's the case. Time will tell (no pun intended) :) Glad to hear your API execution is working as expected too.

kerem commented

2026-03-15 12:46:42 +03:00

Author

Owner

@axllent commented on GitHub (Oct 20, 2023):

@Leobaillard I have just released this feature in v.1.9.9. Please let me know how you get on? Thanks :-)

@axllent commented on GitHub (Oct 20, 2023): @Leobaillard I have just released this feature in [v.1.9.9](https://github.com/axllent/mailpit/releases/tag/v1.9.9). Please let me know how you get on? Thanks :-)

kerem commented

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

Author

Owner

@Leobaillard commented on GitHub (Oct 20, 2023):

Awesome! Thank you very much, I will update my Mailpit right now and get back to you when it runs!

@Leobaillard commented on GitHub (Oct 20, 2023): Awesome! Thank you very much, I will update my Mailpit right now and get back to you when it runs!

kerem commented

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

Author

Owner

@Leobaillard commented on GitHub (Oct 23, 2023):

Works great, I can see the updated date aligned with the delivery date. Thanks again! I'll close the issue.

@Leobaillard commented on GitHub (Oct 23, 2023): Works great, I can see the updated date aligned with the delivery date. Thanks again! I'll close the issue.

Rows
Columns

[GH-ISSUE #194] Feature request: Reset message date on release #129