[GH-ISSUE #234] Release Functionality Does Not Honor "Send To" Addresses Specified in UI #152

Closed
opened 2026-03-15 12:52:55 +03:00 by kerem · 7 comments
Owner

Originally created by @tonyswu on GitHub (Jan 9, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/234

First of all, thanks for the release function implemented by https://github.com/axllent/mailpit/issues/29. We just now started to test it, and have found a bug where the emails entered in the UI aren't being honored. A secondary bug, as a result of this, is that if the original To address is not on the recipient-allowlist, this actually bypasses it and allows it to be sent since the address the email is actually sent to isn't the one validated.

Background on our setup:

  1. Mailpit container, listening on port 25, configured to relay to localhost:10025. Mailpit is also configured with recipient-allowlist as, say, @mac\.com$.
  2. A postfix container, listening on port 10025, configured to further relay to AWS SES.
  3. AWS SES is in SANDBOX mode, meaning only addresses verified by SES manually are sent.

For the purpose of demo, let's say we have two email addresses:

  • tonyswu@mac.com: Verified by AWS SES.
  • tonyswu.mac@gmail.com: NOT verified by AWS SES.

To reproduce:

  1. First, generate a test email. For the purpose of demonstrating both bug, we'll have this sent to the email NOT verified by AWS SES:
echo "Test" | mailx -vvv -s "Test Subject" -S smtp=localhost -r "noreply@example.com" "tonyswu.mac@gmail.com"
  1. Find email in Mailpit, and attempt to release it, which shows an error. This is working as intended, since @gmail.com isn't in the recipient-allowlist.

  2. Repeat step 2, except now we'll remove tonyswu.mac@gmail.com and put in tonyswu@mac.com. Once clicking on release UI responds with OK status.

  3. On the downstream postfix, we see the email is still getting sent to the address tonyswu.mac@gmail.com (error message is from AWS SES). And no email is sent to tonyswu@mac.com at all.

2024-01-09T20:54:52.348Z [ERROR] Flow(localhost) Output(aws_0) MessageRejected: Email address is not verified. The following identities failed the check in region US-WEST-2: tonyswu.mac@gmail.com

I've also verified that the API is indeed sent with the correct To data, so I do not think this is an UI issue, and potentially may be a problem with perhaps smtpd where the messages are written without changing the To field first.

Originally created by @tonyswu on GitHub (Jan 9, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/234 First of all, thanks for the release function implemented by https://github.com/axllent/mailpit/issues/29. We just now started to test it, and have found a bug where the emails entered in the UI aren't being honored. A secondary bug, as a result of this, is that if the original To address is not on the `recipient-allowlist`, this actually bypasses it and allows it to be sent since the address the email is actually sent to isn't the one validated. Background on our setup: 1. Mailpit container, listening on port 25, configured to relay to localhost:10025. Mailpit is also configured with `recipient-allowlist` as, say, `@mac\.com$`. 2. A postfix container, listening on port 10025, configured to further relay to AWS SES. 3. AWS SES is in SANDBOX mode, meaning only addresses verified by SES manually are sent. For the purpose of demo, let's say we have two email addresses: * `tonyswu@mac.com`: Verified by AWS SES. * `tonyswu.mac@gmail.com`: NOT verified by AWS SES. To reproduce: 1. First, generate a test email. For the purpose of demonstrating both bug, we'll have this sent to the email NOT verified by AWS SES: ``` echo "Test" | mailx -vvv -s "Test Subject" -S smtp=localhost -r "noreply@example.com" "tonyswu.mac@gmail.com" ``` 2. Find email in Mailpit, and attempt to release it, which shows an error. This is working as intended, since `@gmail.com` isn't in the `recipient-allowlist`. 3. Repeat step 2, except now we'll remove `tonyswu.mac@gmail.com` and put in `tonyswu@mac.com`. Once clicking on release UI responds with OK status. 4. On the downstream postfix, we see the email is still getting sent to the address `tonyswu.mac@gmail.com` (error message is from AWS SES). And no email is sent to `tonyswu@mac.com` at all. ``` 2024-01-09T20:54:52.348Z [ERROR] Flow(localhost) Output(aws_0) MessageRejected: Email address is not verified. The following identities failed the check in region US-WEST-2: tonyswu.mac@gmail.com ``` I've also verified that the API is indeed sent with the correct `To` data, so I do not think this is an UI issue, and potentially may be a problem with perhaps smtpd where the messages are written without changing the To field first.
kerem closed this issue 2026-03-15 12:53:00 +03:00
Author
Owner

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

Thanks for the detailed report @tonyswu! I'm not too sure what is going on here, but I have a suspicion...

Mailpit does not rewrite / overwrite any of the message headers when relaying a message. It simply takes the message and passes it onto the configured downstream SMTPD service telling it to whom it should be sent to. In your case the message is sent to AWS SES telling it to send the message to tonyswu@mac.com. This is standard practice, as a receiving mail server should NOT be reading the headers of the email itself to decide who to send it to as this information is passed to it when receiving the original message.

To explain it better - if you send a normal message via SMTP with 2 people listed in the To and then have 2 people in BCC, your SMTPD will receive the message with 4 email addresses specified in the SMTP request. Not all 4 will appear in the email headers though (ie: typically no BCC header). Your SMTPD will then send out 4 separate SMTP requests to the various hosts, each of them defining 1 address in the SMTP request - even though the message being passed through still has only two emails listed in the To field.

Now I am wondering is AWS SES works differently - in that it does read the original message to decide who to send it to? I really don't know the answer, and I do not have AWS SES so I can't confirm that either, but I suspect this is a "feature" they have (or "bug"?). I suspect it's a feature which, although communicating over SMTP, differs from regular SMTP servers.

<!-- gh-comment-id:1884089317 --> @axllent commented on GitHub (Jan 10, 2024): Thanks for the detailed report @tonyswu! I'm not too sure what is going on here, but I have a suspicion... Mailpit does not rewrite / overwrite any of the message headers when relaying a message. It simply takes the message and passes it onto the configured downstream SMTPD service telling it to whom it should be sent to. In your case the message is sent to AWS SES telling it to send the message to `tonyswu@mac.com`. This is standard practice, as a receiving mail server should NOT be reading the headers of the email itself to decide who to send it to as this information is passed to it when receiving the original message. To explain it better - if you send a normal message via SMTP with 2 people listed in the `To` and then have 2 people in BCC, your SMTPD will receive the message with 4 email addresses specified in the SMTP request. Not all 4 will appear in the email headers though (ie: typically no BCC header). Your SMTPD will then send out 4 separate SMTP requests to the various hosts, each of them defining 1 address in the SMTP request - even though the message being passed through still has only two emails listed in the `To` field. Now I am wondering is AWS SES works differently - in that it does read the original message to decide who to send it to? I really don't know the answer, and I do not have AWS SES so I can't confirm that either, but I suspect this is a "feature" they have (or "bug"?). I suspect it's a feature which, although communicating over SMTP, differs from regular SMTP servers.
Author
Owner

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

Regarding point 4 (the downstream postfix server), is postfix your relay SMTP server (ie: the one Mailpit is configured to use)? Assuming this is correct, then you should be able to see exactly who the message gets sent to in the postfix logs. I have tested in my setup and it works exactly as expected - postfix will only deliver to the accepted recipients you entered in Mailpit and not any other emails in the To etc.

Now I do not know how your postfix then relays emails to SES - is postfix actually relaying via SES, or delivering to SES? Either way, I believe that that is where the issue lies, not in Mailpit.

<!-- gh-comment-id:1884202615 --> @axllent commented on GitHub (Jan 10, 2024): Regarding point 4 (the downstream postfix server), is postfix your relay SMTP server (ie: the one Mailpit is configured to use)? Assuming this is correct, then you should be able to see exactly who the message gets sent to in the postfix logs. I have tested in my setup and it works exactly as expected - postfix will only deliver to the accepted recipients you entered in Mailpit and not any other emails in the To etc. Now I do not know how your postfix then relays emails to SES - is postfix actually relaying via SES, or delivering to SES? Either way, I _believe_ that that is where the issue lies, not in Mailpit.
Author
Owner

@tonyswu commented on GitHub (Jan 10, 2024):

I did notice that the email that actually arrived in my inbox looked something like tonyswu.mac@gmail.com <tonyswu@mac.com> in the To field. I'll run some additional tests tomorrow and see if I can figure out if it's indeed something to do with the downstream postfix.

<!-- gh-comment-id:1884204496 --> @tonyswu commented on GitHub (Jan 10, 2024): I did notice that the email that actually arrived in my inbox looked something like `tonyswu.mac@gmail.com <tonyswu@mac.com>` in the `To` field. I'll run some additional tests tomorrow and see if I can figure out if it's indeed something to do with the downstream postfix.
Author
Owner

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

That is very interesting, as it's not Mailpit doing that. Do you have come custom postfix rewrites or something? That may be where the issue is...

<!-- gh-comment-id:1884458880 --> @axllent commented on GitHub (Jan 10, 2024): That is very interesting, as it's not Mailpit doing that. Do you have come custom postfix rewrites or something? That may be where the issue is...
Author
Owner

@tonyswu commented on GitHub (Jan 18, 2024):

I ran some additional tests by putting another postfix instance in front of our SES relay, and judging from the postfix instance in-between it seems that emails are being released to both the original To address as well as the address entered at the release window. I believe from my original setup neither email was sent because it's considered as one API request to AWS SES, and was blocked in its entirety.

Can you confirm if this is the case from your end, that emails are being released to both original To address and the one entered by user? If so then this is still a problem since it bypasses the recipient-allowlist. But if you don't see this behavior then I'll close this issue and do some additional digging on my end and see what I am doing wrong.

<!-- gh-comment-id:1899043908 --> @tonyswu commented on GitHub (Jan 18, 2024): I ran some additional tests by putting another postfix instance in front of our SES relay, and judging from the postfix instance in-between it seems that emails are being released to both the original To address as well as the address entered at the release window. I believe from my original setup neither email was sent because it's considered as one API request to AWS SES, and was blocked in its entirety. Can you confirm if this is the case from your end, that emails are being released to both original To address and the one entered by user? If so then this is still a problem since it bypasses the `recipient-allowlist`. But if you don't see this behavior then I'll close this issue and do some additional digging on my end and see what I am doing wrong.
Author
Owner

@axllent commented on GitHub (Jan 19, 2024):

@tonyswu I cannot replicate the issue you are experiencing. As I mentioned before, my instance of postfix is only sending emails listed in the release dialogue. All/any other emails referenced in the email headers (eg: To, Cc) are ignored. Mailpit does not modify those fields, not rewrite any email addresses as you experienced, so that am very confused too. What happens is you remove SES from the process (ie: get postfix to deliver the emails directly), does it work them?

As I also mentioned before, you should be able to see who the email is being sent to based on just the postfix logs too.

I still suspect that SES may be the culprit here, which may be somehow combining the original email data with the "send to" list that postfix should be telling it to use. This assumes though that postfix is delivering emails to SES via SMTP - if it is using some other protocol to deliver to SES then I don't know ....

<!-- gh-comment-id:1899525285 --> @axllent commented on GitHub (Jan 19, 2024): @tonyswu I cannot replicate the issue you are experiencing. As I mentioned before, my instance of postfix is only sending emails listed in the release dialogue. All/any other emails referenced in the email headers (eg: To, Cc) are ignored. Mailpit does not modify those fields, not rewrite any email addresses as you experienced, so that am very confused too. What happens is you remove SES from the process (ie: get postfix to deliver the emails directly), does it work them? As I also mentioned before, you should be able to see who the email is being sent to based on just the postfix logs too. I still suspect that SES may be the culprit here, which may be somehow combining the original email data with the "send to" list that postfix should be telling it to use. This assumes though that postfix is delivering emails to SES via SMTP - if it is using some other protocol to deliver to SES then I don't know ....
Author
Owner

@tonyswu commented on GitHub (Jan 25, 2024):

I see. Since you aren't able to reproduce, I'll consider this resolved. Thanks for entering a discussion with me.

<!-- gh-comment-id:1911188333 --> @tonyswu commented on GitHub (Jan 25, 2024): I see. Since you aren't able to reproduce, I'll consider this resolved. Thanks for entering a discussion with me.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mailpit#152
No description provided.