[GH-ISSUE #29] Email forwarding

kerem commented

2026-03-15 12:09:44 +03:00

Owner

Originally created by @jimafisk on GitHub (Dec 21, 2022).
Original GitHub issue: https://github.com/axllent/mailpit/issues/29

I don't think this is the intention of the project, but wanted to throw an idea out there.

Amazon SES is one of the more economic production SMTP services, but it doesn't offer an interface for seeing which emails are sent to who, at what time, with what contents - that's why projects like SES Dashboard exist.

Mailpit could provide all that context for a production app, but forward along the email to SES for deliverability. Too out of scope? Thanks!

Originally created by @jimafisk on GitHub (Dec 21, 2022). Original GitHub issue: https://github.com/axllent/mailpit/issues/29 I don't think this is the intention of the project, but wanted to throw an idea out there. [Amazon SES](https://aws.amazon.com/ses/) is one of the more economic production SMTP services, but it doesn't offer an interface for seeing which emails are sent to who, at what time, with what contents - that's why projects like [SES Dashboard](https://sesdashboard.com/) exist. Mailpit could provide all that context for a production app, but forward along the email to SES for deliverability. Too out of scope? Thanks!

kerem

2026-03-15 12:09:44 +03:00

closed this issue
added the
enhancement
label

kerem commented

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

Author

Owner

@axllent commented on GitHub (Dec 21, 2022):

@jimafisk Are you meaning that Mailpit would act as a form of transparent caching proxy for email, so it would route it through and store a copy?

@axllent commented on GitHub (Dec 21, 2022): @jimafisk Are you meaning that Mailpit would act as a form of transparent caching proxy for email, so it would route it through and store a copy?

kerem commented

2026-03-15 12:10:05 +03:00

Author

Owner

@jimafisk commented on GitHub (Dec 21, 2022):

Yes exactly. Not suggesting to completely change the direction of the project, trapping emails during development is very useful. Just wondering if it could provide additional capabilities for a prod environment to be an "invisible" layer between your app and SES to log the sent email info?

@jimafisk commented on GitHub (Dec 21, 2022): Yes exactly. Not suggesting to completely change the direction of the project, trapping emails during development is very useful. Just wondering if it could provide additional capabilities for a prod environment to be an "invisible" layer between your app and SES to log the sent email info?

kerem commented

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

Author

Owner

@axllent commented on GitHub (Dec 21, 2022):

Thanks for the explanation. I'll give this some consideration (adding a setting of sorts for an SMTP relay) ~ though I'm a bit hesitant / cautious as something like this could then be used to illegally monitor routed email too. In saying that there are potentially already other existing ways to send duplicate copies of all mail to multiple hosts (I know you can do it by injecting always_bcc=.... into postfix's config), which in turn would also solve your requirement.

@axllent commented on GitHub (Dec 21, 2022): Thanks for the explanation. I'll give this some consideration (adding a setting of sorts for an SMTP relay) ~ though I'm a bit hesitant / cautious as something like this could then be used to illegally monitor routed email too. In saying that there are potentially already other existing ways to send duplicate copies of all mail to multiple hosts (I know you can do it by injecting `always_bcc=....` into postfix's config), which in turn would also solve your requirement.

kerem commented

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

Author

Owner

@tonyswu commented on GitHub (Feb 1, 2023):

+1 on this. In my opinion this is the one feature that made Mailhog almost irreplaceable even with all its problems, is the option to release an email after it's trapped. We use it for development purpose, because sometimes we just want to make sure the emails look the way they should not only in browsers but in various email clients as well.

@tonyswu commented on GitHub (Feb 1, 2023): +1 on this. In my opinion this is the one feature that made Mailhog almost irreplaceable even with all its problems, is the option to release an email after it's trapped. We use it for development purpose, because sometimes we just want to make sure the emails look the way they should not only in browsers but in various email clients as well.

kerem commented

2026-03-15 12:10:20 +03:00

Author

Owner

@axllent commented on GitHub (Feb 2, 2023):

@tonyswu What you are describing is selectively releasing specific emails (like MailHog allows), however @jimafisk is asking for the ability to automatically forward everything as it comes in and keep a copy (like a caching proxy). Both of your requests are related in that they require Mailpit to send (relay) via other SMTP server, however one implementation does it automatically for every email it receives, the other one you select which you want to "release".

If/when I implement this then I will consider both requests to try satisfy both of your requirements. I'm just really short of time at the moment so this will have to sit on the back-burner until I find some time 👍

I do have one question @tonyswu - I remember that MailHog requires you to specify the SMTP server details in the web UI when releasing the email, however I would think it far better to set the SMTP server via either command flags (or environment variables) when starting Mailpit. With your current use case, do you ever need to use different outgoing "release SMTPs", or am I right in assuming that you would only ever have one set for all emails you would release?

@axllent commented on GitHub (Feb 2, 2023): @tonyswu What you are describing is selectively releasing specific emails (like MailHog allows), however @jimafisk is asking for the ability to automatically forward everything as it comes in and keep a copy (like a caching proxy). Both of your requests are related in that they require Mailpit to send (relay) via other SMTP server, however one implementation does it automatically for every email it receives, the other one you select which you want to "release". If/when I implement this then I will consider both requests to try satisfy both of your requirements. I'm just really short of time at the moment so this will have to sit on the back-burner until I find some time :+1: I do have one question @tonyswu - I remember that MailHog requires you to specify the SMTP server details in the web UI when releasing the email, however I would think it far better to set the SMTP server via either command flags (or environment variables) when starting Mailpit. With your current use case, do you ever need to use different outgoing "release SMTPs", or am I right in assuming that you would only ever have one set for all emails you would release?

kerem commented

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

Author

Owner

@tonyswu commented on GitHub (Feb 2, 2023):

For our usecase we only need one "release SMTP", so command line option would be sufficient.

@tonyswu commented on GitHub (Feb 2, 2023): For our usecase we only need one "release SMTP", so command line option would be sufficient.

kerem commented

2026-03-15 12:10:30 +03:00

Author

Owner

@LiamKarlMitchell commented on GitHub (Feb 8, 2023):

Would be nice to have a button in interface that could send email to another email address via some SMTP sender or web sending such as Mailgun/Sendgrid.
It would be useful to allow seeing how the email may appear in some specific email clients such as Outlook/Gmail/Apple and on Mobile device whilst still acting as a catch-all/trap for development servers.

@LiamKarlMitchell commented on GitHub (Feb 8, 2023): Would be nice to have a button in interface that could send email to another email address via some SMTP sender or web sending such as Mailgun/Sendgrid. It would be useful to allow seeing how the email may appear in some specific email clients such as Outlook/Gmail/Apple and on Mobile device whilst still acting as a catch-all/trap for development servers.

kerem commented

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

Author

Owner

@axllent commented on GitHub (Feb 9, 2023):

I haven't started any coding for this yet, other than thinking about the most suitable implementation that will (hopefully) satisfy most use-cases. Currently my thinking is this:

An runtime flag to set a single SMTP "relay server" configuration file. Whilst I'm sure some would like to relay via third-party APIs such as Mailgun or Sendgrid, the truth is there are too many different services to maintain, and most (if not all) support SMTP too. I also don't want to spend my time debugging different services.
A runtime flag to automatically relay all received mails (ie: proxy). This would relay all emails to their original recipient(s) as they are received. There would be zero fault tolerance, so if the relay SMTP server was down or rejects the message for whatever reason, the relayed message would be lost (the error would be logged and the original mail would still be stored in Mailpit though). I do not want to implement a "postfix clone" to handle retries, rejections etc. Mailpit was never designed to be implemented in production as a "caching proxy", so if it is flooded with emails, then it will flood the relaying SMTP with emails too.
If an SMTP relay configuration was provided during startup, the UI would have a button (per email) to release an email. This would default to the original To, Cc & Bcc values, but would allow you to change that before confirming sending.

A point worth noting is that relaying messages would alter somewhat the original mail headers (even if it is slightly), and potentially affect any present DKIM / SFP authentication depending on what relay SMTP is used and whether that aligns. There is no way to avoid this as that's exactly what DKIM / SFP authentication is designed to protect against.

@axllent commented on GitHub (Feb 9, 2023): I haven't started any coding for this yet, other than thinking about the most suitable implementation that will (hopefully) satisfy most use-cases. Currently my thinking is this: - An runtime flag to set a single SMTP "relay server" configuration file. Whilst I'm sure some would like to relay via third-party APIs such as Mailgun or Sendgrid, the truth is there are too many different services to maintain, and most (if not all) support SMTP too. I also don't want to spend my time debugging different services. - A runtime flag to automatically relay all received mails (ie: proxy). This would relay all emails to their original recipient(s) as they are received. There would be zero fault tolerance, so if the relay SMTP server was down or rejects the message for whatever reason, the relayed message would be lost (the error would be logged and the original mail would still be stored in Mailpit though). I do not want to implement a "postfix clone" to handle retries, rejections etc. Mailpit was never designed to be implemented in production as a "caching proxy", so if it is flooded with emails, then it will flood the relaying SMTP with emails too. - If an SMTP relay configuration was provided during startup, the UI would have a button (per email) to release an email. This would default to the original To, Cc & Bcc values, but would allow you to change that before confirming sending. A point worth noting is that relaying messages would alter somewhat the original mail headers (even if it is slightly), and potentially affect any present DKIM / SFP authentication depending on what relay SMTP is used and whether that aligns. There is no way to avoid this as that's exactly what DKIM / SFP authentication is designed to protect against.

kerem commented

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

Author

Owner

@LiamKarlMitchell commented on GitHub (Feb 9, 2023):

Found this from the past, thanks for your consideration.

Mailpit does not have the ability to release emails (relay them to another SMTP). I have no plans to add this either.
https://github.com/axllent/mailpit/issues/15

Agree, SendGrid SMTP for example is well documented so totally fine to just configure the credentials in env vars probably.
https://docs.sendgrid.com/for-developers/sending-email/getting-started-smtp

User: YXBpa2V5 Base64 Encoded username of "apikey"
Pass: YourApiKey Base64 Encoded
Host: smtp.sendgrid.net
Port: SendGrid accepts unencrypted and TLS connections on ports 25, 587, & 2525. You can also connect via SSL on port 465. Many hosting providers and ISPs block port 25 as a default practice. (AWS does as well if I recall).

That makes sense on altering the headers slightly, a real server should be used anyway with something like mxtoolbox to check DKIM/SPF, Mostly curious about testing visually in various email clients and mobile clients manually. Something like https://www.litmus.com/email-testing/ peeks my curiosity but for most projects I only have a couple clients I'm worried about as sometimes styling/buttons come out wrong or other email clients muddle with or strip content, it's normally possible to switch them over to SendGrid temporarily just to check but one of the KEY reasons to use a service such as MailPit is that it traps the emails from development servers so they don't get sent to real addresses/inboxes by accident...

Great stuff thanks

@LiamKarlMitchell commented on GitHub (Feb 9, 2023): Found this from the past, thanks for your consideration. > Mailpit does not have the ability to release emails (relay them to another SMTP). I have no plans to add this either. https://github.com/axllent/mailpit/issues/15 Agree, SendGrid SMTP for example is well documented so totally fine to just configure the credentials in env vars probably. https://docs.sendgrid.com/for-developers/sending-email/getting-started-smtp ``` User: YXBpa2V5 Base64 Encoded username of "apikey" Pass: YourApiKey Base64 Encoded Host: smtp.sendgrid.net Port: SendGrid accepts unencrypted and TLS connections on ports 25, 587, & 2525. You can also connect via SSL on port 465. Many hosting providers and ISPs block port 25 as a default practice. (AWS does as well if I recall). ``` That makes sense on altering the headers slightly, a real server should be used anyway with something like mxtoolbox to check DKIM/SPF, Mostly curious about testing visually in various email clients and mobile clients manually. Something like https://www.litmus.com/email-testing/ peeks my curiosity but for most projects I only have a couple clients I'm worried about as sometimes styling/buttons come out wrong or other email clients muddle with or strip content, it's normally possible to switch them over to SendGrid temporarily just to check but one of the KEY reasons to use a service such as MailPit is that it traps the emails from development servers so they don't get sent to real addresses/inboxes by accident... Great stuff thanks

kerem commented

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

Author

Owner

@gosi-at commented on GitHub (Feb 28, 2023):

* If an SMTP relay configuration was provided during startup, the UI would have a button (per email) to release an email. This would default to the original To, Cc & Bcc values, but would allow you to change that before confirming sending.

that would be greatly appreciated!

@gosi-at commented on GitHub (Feb 28, 2023): > * If an SMTP relay configuration was provided during startup, the UI would have a button (per email) to release an email. This would default to the original To, Cc & Bcc values, but would allow you to change that before confirming sending. that would be greatly appreciated!

kerem commented

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

Author

Owner

@patramsey commented on GitHub (Apr 7, 2023):

@axllent I've put in some work on these features https://github.com/patramsey/mailpit/tree/release-messages in this branch. I can create a PR if it makes sense.

@patramsey commented on GitHub (Apr 7, 2023): @axllent I've put in some work on these features https://github.com/patramsey/mailpit/tree/release-messages in this branch. I can create a PR if it makes sense.

kerem commented

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

Author

Owner

@axllent commented on GitHub (Apr 8, 2023):

@patramsey Thank you. I have taken a quick look and it is actually quite similar to what I originally started doing several weeks ago (but gave up on temporarily). There is a lot more involved in this task to get it working, and also several related complications when it comes to auto-releasing messages - so I have much more to do, and several structural changes to make first. No need for a PR at this stage thanks, but please leave your branch as-is as it is handy for me to refer to when I do get around to restarting this. Email forwarding is definitely still on my radar, in fact it is the next big thing on my list, however I need to make some of the smaller changes first 👍

@axllent commented on GitHub (Apr 8, 2023): @patramsey Thank you. I have taken a quick look and it is actually quite similar to what I originally started doing several weeks ago (but gave up on temporarily). There is a lot more involved in this task to get it working, and also several related complications when it comes to auto-releasing messages - so I have much more to do, and several structural changes to make first. No need for a PR at this stage thanks, but please leave your branch as-is as it is handy for me to refer to when I do get around to restarting this. Email forwarding is definitely still on my radar, in fact it is the next big thing on my list, however I need to make some of the smaller changes first :+1:

kerem commented

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

Author

Owner

@patramsey commented on GitHub (Apr 10, 2023):

@axllent for sure, I'm happy to assist with the complications around auto-releasing messages if you'd like.

I could separate the explicit release via the UI into a different branch from the auto release if that is useful. Maybe the changes you are envisioning don't impact that code path? The explicit release is the feature I'm most interested in and excited about. Our team will then be able to use Mailpit as a replacement for Mailhog!

@patramsey commented on GitHub (Apr 10, 2023): @axllent for sure, I'm happy to assist with the complications around auto-releasing messages if you'd like. I could separate the explicit release via the UI into a different branch from the auto release if that is useful. Maybe the changes you are envisioning don't impact that code path? The explicit release is the feature I'm most interested in and excited about. Our team will then be able to use Mailpit as a replacement for Mailhog!

kerem commented

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

Author

Owner

@axllent commented on GitHub (Apr 11, 2023):

Thank you for the offer @patramsey, but please hold off as there's a good chance I won't merge it, as it'll be more work to undo/redo things as it will be simply to write it the way I have in mind. I understand your urgency for wanting this, but you will just have to be a bit more patient.

@axllent commented on GitHub (Apr 11, 2023): Thank you for the offer @patramsey, but please hold off as there's a good chance I won't merge it, as it'll be more work to undo/redo things as it will be simply to write it the way I have in mind. I understand your urgency for wanting this, but you will just have to be a bit more patient.

kerem commented

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

Author

Owner

@tyler36 commented on GitHub (Apr 13, 2023):

Would love to see this feature implemented.

I recently created ddev-mailpit to intergrate Mailpit into a DDEV project.
The feature discussed in this issue would help bring feature-parity with Mailhog (DDEV's default mail debugger) and maybe help replace it.

@tyler36 commented on GitHub (Apr 13, 2023): Would love to see this feature implemented. I recently created [ddev-mailpit](https://github.com/tyler36/ddev-mailpit) to intergrate Mailpit into a DDEV project. The feature discussed in this issue would help bring feature-parity with Mailhog (DDEV's default mail debugger) and maybe help replace it.

kerem commented

2026-03-15 12:11:16 +03:00

Author

Owner

@JshGrn commented on GitHub (Apr 19, 2023):

+1 to above thanks @axllent 😀

Are you saying this will be developed, but will need to wait for it to be done the way you want it implemented? Is this definitely a go ahead is what I am asking ?

@JshGrn commented on GitHub (Apr 19, 2023): +1 to above thanks @axllent 😀 Are you saying this will be developed, but will need to wait for it to be done the way you want it implemented? Is this definitely a go ahead is what I am asking ?

kerem commented

2026-03-15 12:11:21 +03:00

Author

Owner

@axllent commented on GitHub (Apr 19, 2023):

Just to clarify for everyone waiting for this feature - I am currently actively working hard on it in my free time. It is significantly more complicated than simply "forwarding" (relaying) the email as-is, and so it is taking more time than I expected (to do it correctly). What an email contains in the headers, and the addresses provided in the SMTP request and sometimes not the same (eg: Laravel does not insert Bcc headers in the email when delivering directly via SMTP, but rather provides them in the SMTP request). Given that this ticket was initially for auto-forwarding all email (transparent proxy), which has expanded into the ability to manually relay emails, I have had to cater for all changes at once. For Mailpit to capture/store this "hidden data" (who the email headers say it is for and who is it actually for), I have to effectively recreate the Bcc headers without breaking the original email headers, and when relaying (manually or automatically) I have to then remove the Bcc headers again. This has proved trickier than I expected (to maintain the original headers as much as possible) ~but I have it working now.

So far the release appears to be working nicely - I have a partially working implementation (which won't be ready for release until it is finished). When manually releasing the email, it pre-populates the "send to" field with all the original addresses in the email, but allows you to add or delete from the list. These calls will also be available within the API (the web UI uses the API, so there is documentation which I also have to write for that. I still need to choose a way to configure the system-wide format and options for the relay server. I am planning of only allowing a single regular SMTP server configured in a yaml file, which can then be loaded via a commandline flag or environment variable to configured which file stores this info, then the release functionality will be available in the UI, otherwise not. It was never my plan to allow users configure their own when releasing emails in the web UI (I think MailHog did this).

This UI currently looks something like this when releasing an email:

So as I said, I'm making good progress. I must warn everyone that I have a well-deserved 5-day-break coming up from the end of tomorrow, and I plan to use it to actually take a break and unwind, and not program. At this rate, I would say that hopefully by the end of the month this fully working feature will be released - but that is a little dependent on how many other support queries I get for Mailhog (they take up so much time). If you see questions there which you know the answer to, then please feel free to try assist me by assisting them. Thanks ❤️

@axllent commented on GitHub (Apr 19, 2023): Just to clarify for everyone waiting for this feature - I am currently actively working hard on it in my free time. It is significantly more complicated than simply "forwarding" (relaying) the email as-is, and so it is taking more time than I expected (to do it correctly). What an email contains in the headers, and the addresses provided in the SMTP request and sometimes not the same (eg: Laravel does not insert Bcc headers in the email when delivering directly via SMTP, but rather provides them in the SMTP request). Given that this ticket was initially for auto-forwarding all email (transparent proxy), which has expanded into the ability to manually relay emails, I have had to cater for all changes at once. For Mailpit to capture/store this "hidden data" (who the email headers say it is for and who is it actually for), I have to effectively recreate the Bcc headers without breaking the original email headers, and when relaying (manually or automatically) I have to then remove the Bcc headers again. This has proved trickier than I expected (to maintain the original headers as much as possible) ~but I have it working now. So far the release appears to be working nicely - I have a partially working implementation (which won't be ready for release until it is finished). When manually releasing the email, it pre-populates the "send to" field with all the original addresses in the email, but allows you to add or delete from the list. These calls will also be available within the API (the web UI uses the API, so there is documentation which I also have to write for that. I still need to choose a way to configure the system-wide format and options for the relay server. I am planning of only allowing a single regular SMTP server configured in a yaml file, which can then be loaded via a commandline flag or environment variable to configured which file stores this info, then the release functionality will be available in the UI, otherwise not. It was never my plan to allow users configure their own when releasing emails in the web UI (I think MailHog did this). This UI currently looks something like this when releasing an email: ![Screenshot 2023-04-19 at 22-14-44 Mailpit](https://user-images.githubusercontent.com/1463435/233044346-1defde36-47f0-445a-8627-afe7cf2f84c1.png) So as I said, I'm making good progress. I must warn everyone that I have a well-deserved 5-day-break coming up from the end of tomorrow, and I plan to use it to actually take a break and unwind, and not program. At this rate, I would say that hopefully by the end of the month this fully working feature will be released - but that is a little dependent on how many other support queries I get for Mailhog (they take up so much time). If you see questions there which you know the answer to, then please feel free to try assist me by assisting them. Thanks :heart:

kerem commented

2026-03-15 12:11:26 +03:00

Author

Owner

@axllent commented on GitHub (Apr 21, 2023):

Despite my earlier comment about month-end release, I ended up completing this today (due to bad weather) and and have released it with v1.6.0.

This includes both the ability to "release" a message via the Web UI/API, as well as the original request "proxy" incoming mails automatically to a SMTP server. I have created a wiki page to provide some additional documentation regarding the configuration file and the subtle differences between both options.

I'll close this issue given that there are now too many comments to constructively deal with feedback / issues with the new features. Any issues should be reported via a new Github issue, thanks. PS: I will still be away for a few days so responses will be delayed. Have fun!

@axllent commented on GitHub (Apr 21, 2023): Despite my earlier comment about month-end release, I ended up completing this today (due to bad weather) and and have released it with v1.6.0. This includes both the ability to "release" a message via the Web UI/API, as well as the original request "proxy" incoming mails automatically to a SMTP server. I have created a [wiki page](https://github.com/axllent/mailpit/wiki/SMTP-relay) to provide some additional documentation regarding the configuration file and the subtle differences between both options. I'll close this issue given that there are now too many comments to constructively deal with feedback / issues with the new features. Any issues should be reported via a new Github issue, thanks. PS: I will still be away for a few days so responses will be delayed. Have fun!

Rows
Columns

[GH-ISSUE #29] Email forwarding #26