mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 08:45:54 +03:00
[GH-ISSUE #234] Release Functionality Does Not Honor "Send To" Addresses Specified in UI #152
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#152
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
recipient-allowlistas, say,@mac\.com$.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:
Find email in Mailpit, and attempt to release it, which shows an error. This is working as intended, since
@gmail.comisn't in therecipient-allowlist.Repeat step 2, except now we'll remove
tonyswu.mac@gmail.comand put intonyswu@mac.com. Once clicking on release UI responds with OK status.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 totonyswu@mac.comat all.I've also verified that the API is indeed sent with the correct
Todata, 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.@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
Toand 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 theTofield.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.
@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.
@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 theTofield. 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.@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...
@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.@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 ....
@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.