[GH-ISSUE #547] Feat.: semi-reliable auto-relay #352

New issue

Closed

opened 2026-03-15 14:03:20 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 14:03:20 +03:00

Owner

Originally created by @jods4 on GitHub (Jul 31, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/547

Hi!

I was trying to figure out the behavior of Mailpit when an auto-relay fails.
My (limited) understanding of Go is that:

Relaying is synchronous
If it fails an error is logged
Then the message is still stored and the external sending call still completes successfully

Do you think it would be possible / make sense for the call to Mailpit to fail when relaying failed? Maybe with an option?

The idea here is that if that the SMTP send operation succeeds, then we're sure the mail was relayed to the next SMTP server.

I understand that Mailpit is meant for testing and this is moving into "reliable" territory so maybe you'll think it's not appropriate.

Originally created by @jods4 on GitHub (Jul 31, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/547 Hi! I was trying to figure out the behavior of Mailpit when an auto-relay fails. My (limited) understanding of Go is that: - Relaying is synchronous - If it fails an error is logged - Then the message is still stored and the external sending call still completes successfully Do you think it would be possible / make sense for the call to Mailpit to fail when relaying failed? Maybe with an option? The idea here is that if that the SMTP send operation succeeds, then we're sure the mail was relayed to the next SMTP server. I understand that Mailpit is meant for testing and this is moving into "reliable" territory so maybe you'll think it's not appropriate.

kerem closed this issue

2026-03-15 14:03:25 +03:00

kerem commented

2026-03-15 14:03:31 +03:00

Author

Owner

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

Hi @jods4. Your understanding is correct: When Mailpit is set up to automatically relay messages, it receives new messages via SMTP and attempts to relay them synchronously. Regardless of whether this relaying is successful or not, the message is stored in the database, and any errors encountered during the relaying process are simply logged.

A bit of background: Asynchronous sending was never a viable option because Mailpit can handle hundreds of messages per second. If relaying were asynchronous, it could easily overwhelm the relay server with numerous simultaneous requests. The design aims to ensure that the receiving functionality remains intact; if the relay server cannot manage the load, then that's too bad. This simplicity in relaying was intentional, as I did not want the relay server to "break" Mailpit, and I wanted to avoid implementing a message queue and retry system within Mailpit, which would shift its purpose towards being a full-fledged mail server - something that is beyond its intended scope.

Regarding your request for Mailpit to return an error message to the SMTP client if relaying fails: while this could technically be implemented with some modifications, it is worth considering whether this is a good idea. I've received similar requests in the past that would essentially require Mailpit to function as a complete mail server, including features like queuing, retrying, rejecting, and bounce handling - all of which are far outside its intended purpose.

What I’ve observed is that these requests often stem from a desire for a more reliable relaying system rather than simply returning an error to the client (which may or may not apply to your question). A remote SMTP server can temporarily fail for various reasons, and it seems you might be looking for greater reliability in the relaying process. Have you considered placing a local Postfix server between Mailpit and the relay server (ie: postfix is also a relay server, which relays messages from Mailpit to the other SMTPD)? This setup would allow for fast local delivery to Postfix, which could then manage the relaying to the SMTP server, handling deferrals, queues, and bounces effectively.

@axllent commented on GitHub (Aug 1, 2025): Hi @jods4. Your understanding is correct: When Mailpit is set up to automatically relay messages, it receives new messages via SMTP and attempts to relay them synchronously. Regardless of whether this relaying is successful or not, the message is stored in the database, and any errors encountered during the relaying process are simply logged. A bit of background: Asynchronous sending was never a viable option because Mailpit can handle hundreds of messages per second. If relaying were asynchronous, it could easily overwhelm the relay server with numerous simultaneous requests. The design aims to ensure that the receiving functionality remains intact; if the relay server cannot manage the load, then that's too bad. This simplicity in relaying was intentional, as I did not want the relay server to "break" Mailpit, and I wanted to avoid implementing a message queue and retry system within Mailpit, which would shift its purpose towards being a full-fledged mail server - something that is beyond its intended scope. Regarding your request for Mailpit to return an error message to the SMTP client if relaying fails: while this could technically be implemented with some modifications, it is worth considering whether this is a good idea. I've received similar requests in the past that would essentially require Mailpit to function as a complete mail server, including features like queuing, retrying, rejecting, and bounce handling - all of which are far outside its intended purpose. What I’ve observed is that these requests often stem from a desire for a more reliable relaying system rather than simply returning an error to the client (which may or may not apply to your question). A remote SMTP server can temporarily fail for various reasons, and it seems you might be looking for greater reliability in the relaying process. Have you considered placing a local Postfix server between Mailpit and the relay server (ie: postfix is also a relay server, which relays messages from Mailpit to the other SMTPD)? This setup would allow for fast local delivery to Postfix, which could then manage the relaying to the SMTP server, handling deferrals, queues, and bounces effectively.

kerem commented

2026-03-15 14:03:36 +03:00

Author

Owner

@jods4 commented on GitHub (Aug 4, 2025):

Thanks for your answer @axllent !

In my specific case my application does already perform the queuing, retries, etc. when contacting our SMTP server. So I would be fine if Mailpit would just passthrough the errors when relaying. That said I understand your position, feel free to close this issue if you don't think it fits with Mailpit goals.

A related point I was considering is whether Mailpit can "not store" specific emails, e.g. if they are tagged as sensitive, or if there was a way to "redact" stored emails, e.g. with a regex to remove certain parts?

@jods4 commented on GitHub (Aug 4, 2025): Thanks for your answer @axllent ! In my specific case my application does already perform the queuing, retries, etc. when contacting our SMTP server. So I would be fine if Mailpit would just passthrough the errors when relaying. That said I understand your position, feel free to close this issue if you don't think it fits with Mailpit goals. A related point I was considering is whether Mailpit can "not store" specific emails, e.g. if they are tagged as sensitive, or if there was a way to "redact" stored emails, e.g. with a regex to remove certain parts?

kerem commented

2026-03-15 14:03:41 +03:00

Author

Owner

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

I have given this much thought and some investigation in the last week, but have come back to the conclusion that this is out-of-scope for the project. To handle these kinds of features I would need to add a considerable amount of new functionality, making it more and more complicated to maintain. Who knows, maybe one day, but not in the foreseeable future 👍 Sorry.

@axllent commented on GitHub (Aug 10, 2025): I have given this much thought and some investigation in the last week, but have come back to the conclusion that this is out-of-scope for the project. To handle these kinds of features I would need to add a considerable amount of new functionality, making it more and more complicated to maintain. Who knows, maybe one day, but not in the foreseeable future 👍 Sorry.

kerem referenced this issue

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

[PR #352] [CLOSED] Chore: Bump dayjs from 1.11.12 to 1.11.13 #526