kerem commented

Owner

Originally created by @brjppru on GitHub (Dec 27, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/414

Question:

Is it possible to add two new options for handling emails, for example:

MP_SMTP_RELAY_RETURN_PATH
MP_SMTP_RELAY_OVERRIDE_FROM
MP_SMTP_RELAY_OVERRIDE_TO

These options are needed for forwarding emails via MP_SMTP_RELAY_HOST, as some servers reject emails if the From: field does not match the login used for authentication (MP_SMTP_RELAY_USERNAME).

Alternatively, would it make sense to introduce a single setting that automatically sets both the From and To fields to match the MP_SMTP_RELAY_USERNAME?

Thank you!

Originally created by @brjppru on GitHub (Dec 27, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/414 Question: Is it possible to add two new options for handling emails, for example: MP_SMTP_RELAY_RETURN_PATH MP_SMTP_RELAY_OVERRIDE_FROM MP_SMTP_RELAY_OVERRIDE_TO These options are needed for forwarding emails via MP_SMTP_RELAY_HOST, as some servers reject emails if the From: field does not match the login used for authentication (MP_SMTP_RELAY_USERNAME). Alternatively, would it make sense to introduce a single setting that automatically sets both the From and To fields to match the MP_SMTP_RELAY_USERNAME? Thank you!

kerem

2026-03-15 13:33:21 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-15 13:33:37 +03:00

Author

Owner

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

Hi @brjppru, apologies for the delay (I was taking some time off over the festive season). This type of functionality really doesn't quality as a "relay", it's more a "forward" than anything else.

I understand your point about the From address (although my answer would be to "use a different SMTP server"), but I'm more curious as to why you want to hardcode the To - I am curious as to what you are trying to achieve here exactly?

@axllent commented on GitHub (Jan 1, 2025): Hi @brjppru, apologies for the delay (I was taking some time off over the festive season). This type of functionality really doesn't quality as a "relay", it's more a "forward" than anything else. I understand your point about the From address (although my answer would be to "use a different SMTP server"), but I'm more curious as to why you want to hardcode the `To` - I am curious as to what you are trying to achieve here exactly?

kerem commented

2026-03-15 13:33:42 +03:00

Author

Owner

@brjppru commented on GitHub (Jan 1, 2025):

Thank you for your message! First of all, Merry Christmas and Happy New Year! 🎄✨

I’m working on debugging my app and email distribution system. I have a user database, and here’s how I want to use it: I have an external SMTP server that requires authentication (the app already handles that), and I want to send unique, legal emails to my users—all of whom are authorized. However, the SMTP server only allows sending emails from the address used during authentication (the "From" field).

What I’d like to do is modify the "To" field so that all emails are sent to my own address (which matches the "From" address) to test how the emails appear across various clients—Outlook, Apple Mail, and multiple Android email apps—before finalizing the design. Let me know if this setup makes sense or if there’s a better way to handle it.

I want to debug by sending emails from myself to myself through my server to check how the email layout displays across different clients. My mailbox is already connected to various email clients via IMAP.

I would be glad if you could add functionality that allows overriding the "From" and "To" fields in emails using variables for different environments.

Thank you!

@brjppru commented on GitHub (Jan 1, 2025): Thank you for your message! First of all, Merry Christmas and Happy New Year! 🎄✨ I’m working on debugging my app and email distribution system. I have a user database, and here’s how I want to use it: I have an external SMTP server that requires authentication (the app already handles that), and I want to send unique, legal emails to my users—all of whom are authorized. However, the SMTP server only allows sending emails from the address used during authentication (the "From" field). What I’d like to do is modify the "To" field so that all emails are sent to my own address (which matches the "From" address) to test how the emails appear across various clients—Outlook, Apple Mail, and multiple Android email apps—before finalizing the design. Let me know if this setup makes sense or if there’s a better way to handle it. I want to debug by sending emails from myself to myself through my server to check how the email layout displays across different clients. My mailbox is already connected to various email clients via IMAP. I would be glad if you could add functionality that allows overriding the "From" and "To" fields in emails using variables for different environments. Thank you!

kerem commented

2026-03-15 13:33:48 +03:00

Author

Owner

@bldrdash commented on GitHub (Jan 4, 2025):

Hi @axllent , I came here looking for the exact same thing.

Use case for me that services such as SES or Sendgrid will reject a message if the FROM domain hasn't already been setup. I may have a system that is sending a message from root@localhost that I'd like to eventually forward on, and SES isn't going to allow me to verify the "localhost" TLD, or localhost.local or gitea.local, etc.

It can be a chore to lookup the documentation for sendmail/postfix/exim/applicationX so that the FROM address is in proper form, and sometimes it isn't even possible.

Without the ability to change the from address, there is no way to forward the email on through one of these SMTP services.

In addition to the original request, I'd have one more: include the original FROM address. For example:
MP_SMTP_RELAY_OVERRIDE_FROM=me@example.com
MP_SMTP_MUNGE_FROM=_

This would take the FROM address "root@gitea.local" and change it to:
"root_gitea.local <me@example.com>"

The result would be I'd be able to see the original sender in my email client. The MP_SMTP_MUNGE_FROM value would be what to replace the "@" with.

Thank you for your consideration --

@bldrdash commented on GitHub (Jan 4, 2025): Hi @axllent , I came here looking for the exact same thing. Use case for me that services such as SES or Sendgrid will reject a message if the FROM domain hasn't already been setup. I may have a system that is sending a message from root@localhost that I'd like to eventually forward on, and SES isn't going to allow me to verify the "localhost" TLD, or localhost.local or gitea.local, etc. It can be a chore to lookup the documentation for sendmail/postfix/exim/applicationX so that the FROM address is in proper form, and sometimes it isn't even possible. Without the ability to change the from address, there is no way to forward the email on through one of these SMTP services. In addition to the original request, I'd have one more: include the original FROM address. For example: MP_SMTP_RELAY_OVERRIDE_FROM=me@example.com MP_SMTP_MUNGE_FROM=_ This would take the FROM address "root@gitea.local" and change it to: "root_gitea.local \<me@example.com\>" The result would be I'd be able to see the original sender in my email client. The MP_SMTP_MUNGE_FROM value would be what to replace the "@" with. Thank you for your consideration --

kerem commented

2026-03-15 13:33:53 +03:00

Author

Owner

@axllent commented on GitHub (Jan 6, 2025):

@brjppru & @bldrdash - firstly I believe the existing yaml return-path (or MP_SMTP_RELAY_RETURN_PATH environment) may solve your From address" issues. When it comes to SMTP, the return path is what the SMTP client tells the server the email is from, regardless what is actually in the email header itself (ie: mail servers do not read the email itself to decide who to send to, they are told by the sending SMTP client). The return path is also written / updated in the email header, but it really shouldn't matter what the email header From actually says. Are both you able to confirm for me please if setting the MP_SMTP_RELAY_RETURN_PATH solves your sending issue?

@brjppru - assuming what I just wrote above is correct and does sort that part of your question, then this just leaves the To. You want to force everything to go to a single address. Again, like the From address, we don't actually need to modify the email header itself, the SMTP client (Mailpit) just needs to tell the remote SMTP server who to send to during the SMTP transaction (just like with BCC messages). Theoretically this should be simple enough, however this also impacts the web UI (email release) because that currently allows you to set who to send it to. If we are going to enforce the To, then I will need to account for this in the UI to avoid confusion. I'll wait for confirmation about the first paragraph first before deciding how to handle this.

@axllent commented on GitHub (Jan 6, 2025): @brjppru & @bldrdash - firstly I believe the [existing](https://mailpit.axllent.org/docs/configuration/smtp-relay/) yaml `return-path` (or `MP_SMTP_RELAY_RETURN_PATH` environment) may solve your From address" issues. When it comes to SMTP, the return path is what the SMTP client tells the server the email is from, regardless what is actually in the email header itself (ie: mail servers do not read the email itself to decide who to send to, they are told by the sending SMTP client). The return path is also written / updated in the email header, but it really shouldn't matter what the email header From actually says. Are both you able to confirm for me please if setting the `MP_SMTP_RELAY_RETURN_PATH` solves your sending issue? @brjppru - assuming what I just wrote above is correct and does sort that part of your question, then this just leaves the `To`. You want to force everything to go to a single address. Again, like the From address, we don't actually need to modify the email header itself, the SMTP client (Mailpit) just needs to tell the remote SMTP server who to send to during the SMTP transaction (just like with BCC messages). Theoretically this should be simple enough, however this also impacts the web UI (email release) because that currently allows you to set who to send it to. If we are going to enforce the To, then I will need to account for this in the UI to avoid confusion. I'll wait for confirmation about the first paragraph first before deciding how to handle this.

kerem commented

2026-03-15 13:33:58 +03:00

Author

Owner

@brjppru commented on GitHub (Jan 6, 2025):

Unfortunately no, my server only accepts emails if I substitute the from field, even if I specify a valid MP_SMTP_RELAY_RETURN_PATH, I get a reject for relay. That's why I came with such a request.

@brjppru commented on GitHub (Jan 6, 2025): Unfortunately no, my server only accepts emails if I substitute the from field, even if I specify a valid MP_SMTP_RELAY_RETURN_PATH, I get a reject for relay. That's why I came with such a request.

kerem commented

2026-03-15 13:34:03 +03:00

Author

Owner

@brjppru commented on GitHub (Jan 6, 2025):

I realize that the case with malicious mail servers and from + to substitution for replay is not a common situation. I don't think it should be displayed in the web interface for the mass user, but if you explicitly specify by hand that you auth = from + to, then I would like to see these simultaneous rule matches work

rewrite: mail from : dev@dev.ps.kz
rewrite: mail to: dev@dev.ps.kz
rewrite: auth for: dev@dev.ps.kz

environment:
MP_MAX_MESSAGES: 5000
MP_SMTP_AUTH_ALLOW_INSECURE: true
MP_USE_MESSAGE_DATES: true
MP_SMTP_AUTH_ACCEPT_ANY: true
MP_SMTP_DISABLE_RDNS: true
MP_SMTP_RELAY_ALL: true
MP_SMTP_RELAY_HOST: 192.168.0.27
MP_SMTP_RELAY_USERNAME: dev@dev.ps.kz
MP_SMTP_RELAY_PASSWORD: mysuperdevpass
MP_SMTP_RELAY_RETURN_PATH: dev@dev.ps.kz
MP_ALLOW_UNTRUSTED_TLS: true

+++

MP_SMTP_RELAY_OVERRIDE_FROM: dev@dev.ps.kz
MP_SMTP_RELAY_OVERRIDE_TO: dev@dev.ps.kz

in fact, can say that we are forcing catch-all but for relay

@brjppru commented on GitHub (Jan 6, 2025): I realize that the case with malicious mail servers and from + to substitution for replay is not a common situation. I don't think it should be displayed in the web interface for the mass user, but if you explicitly specify by hand that you auth = from + to, then I would like to see these simultaneous rule matches work 1. rewrite: mail from : dev@dev.ps.kz 2. rewrite: mail to: dev@dev.ps.kz 3. rewrite: auth for: dev@dev.ps.kz environment: MP_MAX_MESSAGES: 5000 MP_SMTP_AUTH_ALLOW_INSECURE: true MP_USE_MESSAGE_DATES: true MP_SMTP_AUTH_ACCEPT_ANY: true MP_SMTP_DISABLE_RDNS: true MP_SMTP_RELAY_ALL: true MP_SMTP_RELAY_HOST: 192.168.0.27 MP_SMTP_RELAY_USERNAME: dev@dev.ps.kz MP_SMTP_RELAY_PASSWORD: mysuperdevpass MP_SMTP_RELAY_RETURN_PATH: dev@dev.ps.kz MP_ALLOW_UNTRUSTED_TLS: true +++ MP_SMTP_RELAY_OVERRIDE_FROM: dev@dev.ps.kz MP_SMTP_RELAY_OVERRIDE_TO: dev@dev.ps.kz in fact, can say that we are forcing catch-all but for relay

kerem commented

2026-03-15 13:34:08 +03:00

Author

Owner

@axllent commented on GitHub (Jan 6, 2025):

Yeah, I don't think I can solve this (logically) with "relaying" - it's effectively "forwarding". They are fundamentally very different things, and by trying to modify relaying to override From and To, it's no longer relaying. It gets super-confusing when relaying is something that can be triggered manually via the UI.

I need to give this more thought, however my current thoughts are as follows... A new set of configuration options that can be used in combination with relaying or not (ie: they are not linked):

MP_SMTP_FORWARDING_TO=<to-email>                        # required
MP_SMTP_FORWARDING_FROM=<from-email>                    # optional
MP_SMTP_FORWARDING_HOST=<hostname-or-ip>                # required
MP_SMTP_FORWARDING_PORT=<port>                          # optional - default 25
MP_SMTP_FORWARDING_STARTTLS=<true|false>                # optional - default false
MP_SMTP_FORWARDING_ALLOW_INSECURE=<true|false>          # optional - default false
MP_SMTP_FORWARDING_AUTH=<none|plain|login|cram-md5>     # optional - default none
MP_SMTP_FORWARDING_USERNAME=<username>                  # required for plain, login and cram-md5 auth
MP_SMTP_FORWARDING_PASSWORD=<password>                  # required for plain & login auth
MP_SMTP_FORWARDING_SECRET=<cram-secret>                 # required for cram-md5 auth

If From is set, then the original From gets replaced with this, and the old From gets inserted as a new header X-ORIGINAL-FROM or something. The original "To" & CC headers shouldn't need modifying, the SMTP server is supposed to read this from the SMTP client which would then tell it to use the MP_SMTP_FORWARDING_TO instead.

Sorry @bldrdash , I don't like the idea of MP_SMTP_MUNGE_FROM as the From header is very fluid, and to try get this right would be prone to all kinds of potential issues - I'd rather just copy/paste the header into another header ~ I assume that would work for you?

@axllent commented on GitHub (Jan 6, 2025): Yeah, I don't think I can solve this (logically) with "relaying" - it's effectively "forwarding". They are fundamentally very different things, and by trying to modify relaying to override From and To, it's no longer relaying. It gets super-confusing when relaying is something that can be triggered manually via the UI. I need to give this more thought, however my **_current_** thoughts are as follows... A new set of configuration options that can be used in combination with relaying or not (ie: they are not linked): ``` MP_SMTP_FORWARDING_TO=<to-email> # required MP_SMTP_FORWARDING_FROM=<from-email> # optional MP_SMTP_FORWARDING_HOST=<hostname-or-ip> # required MP_SMTP_FORWARDING_PORT=<port> # optional - default 25 MP_SMTP_FORWARDING_STARTTLS=<true|false> # optional - default false MP_SMTP_FORWARDING_ALLOW_INSECURE=<true|false> # optional - default false MP_SMTP_FORWARDING_AUTH=<none|plain|login|cram-md5> # optional - default none MP_SMTP_FORWARDING_USERNAME=<username> # required for plain, login and cram-md5 auth MP_SMTP_FORWARDING_PASSWORD=<password> # required for plain & login auth MP_SMTP_FORWARDING_SECRET=<cram-secret> # required for cram-md5 auth ``` If From is set, then the original From gets replaced with this, and the old From gets inserted as a new header `X-ORIGINAL-FROM` or something. The original "To" & CC headers shouldn't need modifying, the SMTP server is supposed to read this from the SMTP client which would then tell it to use the `MP_SMTP_FORWARDING_TO` instead. Sorry @bldrdash , I don't like the idea of `MP_SMTP_MUNGE_FROM` as the From header is very fluid, and to try get this right would be prone to all kinds of potential issues - I'd rather just copy/paste the header into another header ~ I assume that would work for you?

kerem commented

2026-03-15 13:34:13 +03:00

Author

Owner

@brjppru commented on GitHub (Jan 6, 2025):

In fact, if we move away from the application and back to mail, we have two processes

mail accumulation in mailpit itself and relay to smtp - already implemented
mail accumulation in mailpit and forwarding it to the specified address via smtp server (+from +to +smtp +auth)

The first and the second deliver mail, but the logical component is different. i agree with you completely that what i am asking you to implement from the application point of view is additional forwarding, not delivery (relay) of mail to the box.

As in this case two mechanisms can work 1) accumulation of mail 2) delivery by smtp relay 3) delivery by forwarding settings

If you manage to realize this point, I will be very happy!

@brjppru commented on GitHub (Jan 6, 2025): In fact, if we move away from the application and back to mail, we have two processes 1) mail accumulation in mailpit itself and relay to smtp - already implemented 2) mail accumulation in mailpit and forwarding it to the specified address via smtp server (+from +to +smtp +auth) The first and the second deliver mail, but the logical component is different. i agree with you completely that what i am asking you to implement from the application point of view is additional forwarding, not delivery (relay) of mail to the box. As in this case two mechanisms can work 1) accumulation of mail 2) delivery by smtp relay 3) delivery by forwarding settings If you manage to realize this point, I will be very happy!

kerem commented

2026-03-15 13:34:18 +03:00

Author

Owner

@brjppru commented on GitHub (Jan 6, 2025):

In fact, since this is a delivery, it is probably possible to implement a forwarding mechanism directly to imap, bypassing smtp. (well, we won't consider complex relay via other smtp, but smtp -> imap -> storage for forwarded messages), but this complicates the functionality of the application, and I'm not sure I should ask you to do it.

In fact, I need the mail to end up in the imap mailbox, the settings could be like this, e.g.

cat config.txt | grep imap

imap-email-protocol = imap
imap-auth = True
imap-username = dev@dev.ps.kz
imap-password = superstylin
imap-server = groove.armada.uk
imap-port = 993
imap-ssl = True
imap-mailbox = debuglab

@brjppru commented on GitHub (Jan 6, 2025): In fact, since this is a delivery, it is probably possible to implement a forwarding mechanism directly to imap, bypassing smtp. (well, we won't consider complex relay via other smtp, but smtp -> imap -> storage for forwarded messages), but this complicates the functionality of the application, and I'm not sure I should ask you to do it. In fact, I need the mail to end up in the imap mailbox, the settings could be like this, e.g. # cat config.txt | grep imap imap-email-protocol = imap imap-auth = True imap-username = dev@dev.ps.kz imap-password = superstylin imap-server = groove.armada.uk imap-port = 993 imap-ssl = True imap-mailbox = debuglab

kerem commented

2026-03-15 13:34:23 +03:00

Author

Owner

@axllent commented on GitHub (Jan 8, 2025):

In fact, since this is a delivery, it is probably possible to implement a forwarding mechanism directly to imap, bypassing smtp. (well, we won't consider complex relay via other smtp, but smtp -> imap -> storage for forwarded messages), but this complicates the functionality of the application, and I'm not sure I should ask you to do it.

Yeah, direct delivery to an IMAP server falls well outside of the scope of this project, so that's not a good move as it adds a lot of complexity and doesn't benefit the thousands of other Mailpit users.

As a suggestion - if your goal is simply getting a copy of the messages into another mail server, then my not pull those messages via POP3 (which already exists), or even configure your email clients to fetch the messages directly from Mailpit via POP3?

@axllent commented on GitHub (Jan 8, 2025): > In fact, since this is a delivery, it is probably possible to implement a forwarding mechanism directly to imap, bypassing smtp. (well, we won't consider complex relay via other smtp, but smtp -> imap -> storage for forwarded messages), but this complicates the functionality of the application, and I'm not sure I should ask you to do it. Yeah, direct delivery to an IMAP server falls well outside of the scope of this project, so that's not a good move as it adds a lot of complexity and doesn't benefit the thousands of other Mailpit users. As a suggestion - if your goal is simply getting a copy of the messages into another mail server, then my not pull those messages via [POP3](https://mailpit.axllent.org/docs/configuration/pop3/) (which already exists), or even configure your email clients to fetch the messages directly from Mailpit via POP3?

kerem commented

2026-03-15 13:34:28 +03:00

Author

Owner

@brjppru commented on GitHub (Jan 9, 2025):

We’re moving from a push model, where mail is delivered, to a pull model, where it needs to be fetched. This means I’d have to access Mailpit within the network, open up things in the firewall, and ensure full connectivity. That’s a bit beyond the scope of a straightforward mail delivery task like SMTP push :-(

@brjppru commented on GitHub (Jan 9, 2025): We’re moving from a push model, where mail is delivered, to a pull model, where it needs to be fetched. This means I’d have to access Mailpit within the network, open up things in the firewall, and ensure full connectivity. That’s a bit beyond the scope of a straightforward mail delivery task like SMTP push :-(

kerem commented

2026-03-15 13:34:33 +03:00

Author

Owner

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

That's a fair point, although I had no understanding of your infrastructure/network of course. Pushing to IMAP is not an option, so we're back to forwarding via SMTP.

I will add a configuration for SMTP forwarding, which only differs slightly to relaying in that the To address needs to be specified. The From will become an optional flag for both relaying and forwarding to address the SMTP restriction you both have. Forwarding will be a separate configuration to relaying to avoid confusion and complications in the web UI (relaying). Forwarding will not be a manually triggered option via the web UI - it will auto-forward messages as they arrive in Mailpit.

It is worth noting a couple of points about forwarding (the same points apply for relaying): Mailpit does not and will not have any fault tolerance if there is an issue delivering mail. There is no queue, retry, or delivery delays - Mailpit will attempt to deliver the emails immediately as they are received, and it will ignore failures (they are logged in the console though). If Mailpit receives 100 messages per second, it's going to spawn 100 simultaneous SMTP connections per second to the forwarding SMTP server. I'm only stating this so it's absolutely clear that Mailpit is not postfix, it's an SMTP & email testing tool designed for receiving emails, not sending them. If this is going to be an issue then I need to know this now, and you will possibly have to rethink your intended testing routine.

I'm not sure exactly when I'll start on this - hopefully soon, however I am still recovering from shoulder surgery so I don't have a lot of energy or capability at the moment.

@axllent commented on GitHub (Jan 10, 2025): That's a fair point, although I had no understanding of your infrastructure/network of course. Pushing to IMAP is not an option, so we're back to forwarding via SMTP. I will add a configuration for SMTP forwarding, which only differs slightly to relaying in that the `To` address needs to be specified. The `From` will become an optional flag for both relaying and forwarding to address the SMTP restriction you both have. Forwarding will be a separate configuration to relaying to avoid confusion and complications in the web UI (relaying). Forwarding will not be a manually triggered option via the web UI - it will auto-forward messages as they arrive in Mailpit. It is worth noting a couple of points about forwarding (the same points apply for relaying): Mailpit does not and will not have any fault tolerance if there is an issue delivering mail. There is no queue, retry, or delivery delays - Mailpit will attempt to deliver the emails immediately as they are received, and it will ignore failures (they are logged in the console though). If Mailpit receives 100 messages per second, it's going to spawn 100 simultaneous SMTP connections per second to the forwarding SMTP server. I'm only stating this so it's absolutely clear that Mailpit is not postfix, it's an SMTP & email testing tool designed for receiving emails, not sending them. If this is going to be an issue then I need to know this now, and you will possibly have to rethink your intended testing routine. I'm not sure exactly when I'll start on this - hopefully soon, however I am still recovering from shoulder surgery so I don't have a lot of energy or capability at the moment.

kerem commented

2026-03-15 13:34:38 +03:00

Author

Owner

@axllent commented on GitHub (Jan 26, 2025):

I have just released v1.22.0 which I hope solves both your issues (please read the release notes and linked documentation):

Relaying: A new option for overriding the From email in the email itself as well as the SMTP request.
Forwarding: a new feature which auto-forwards all messages to set email addresses. This feature also allows you to override the From email address in both the email itself as well as the SMTP request.

Please confirm this works for you both, thank you.

@axllent commented on GitHub (Jan 26, 2025): I have just released [v1.22.0](https://github.com/axllent/mailpit/releases/tag/v1.22.0) which I hope solves both your issues (please read the release notes and linked documentation): 1. Relaying: A new option for overriding the From email in the email itself as well as the SMTP request. 2. Forwarding: a new feature which auto-forwards all messages to set email addresses. This feature also allows you to override the From email address in both the email itself as well as the SMTP request. Please confirm this works for you both, thank you.

kerem commented

2026-03-15 13:34:44 +03:00

Author

Owner

@axllent commented on GitHub (Feb 6, 2025):

I'm marking this as complete as there as been no feedback.

@axllent commented on GitHub (Feb 6, 2025): I'm marking this as complete as there as been no feedback.

kerem commented

2026-03-15 13:34:49 +03:00

Author

Owner

@bldrdash commented on GitHub (Mar 19, 2025):

@axllent My apologies for not providing feedback earlier; simply didn't see the notice.

The updates in v1.22.0 (and later) worked for me. SES was not only verifying the From address in the envelope, but also the header. override-from resolved this for me. Thank you!

@bldrdash commented on GitHub (Mar 19, 2025): @axllent My apologies for not providing feedback earlier; simply didn't see the notice. The updates in v1.22.0 (and later) worked for me. SES was not only verifying the From address in the envelope, but also the header. `override-from` resolved this for me. Thank you!

kerem commented

2026-03-15 13:34:54 +03:00

Author

Owner

@axllent commented on GitHub (Mar 19, 2025):

Great. Thanks for the feedback.

@axllent commented on GitHub (Mar 19, 2025): Great. Thanks for the feedback.

Rows
Columns

[GH-ISSUE #414] add overrides for: from and to #268

cat config.txt | grep imap