Was testing out mailbox.org email for a bit and ran into an issue with replying to alias emails (Mailbox <> Addy <> Recipient). Anytime I would hit reply to an aliased email, it would put my addy alias as the recipient, rather than the actual aliased recipient email (email_here+sender_email=test.com@addy.io). This would basically send an email from my mailbox account to my addy alias, which would send the email right back to me. I did make a support ticket and they were not able to replicate this.
Just wanted to see if others have had a different experience using an alias on Mailbox. I tried both reply and reply all and ran into the same issue. I would have to log into Addy.io each time to then get the aliased recipient email, and then send out the email.
It’s been about two years since I used the combination of Mailbox.org and Addy before switching to Simplelogin. But back then, everything worked without any problems for me.
It was a verified recipient. When using tuta or Proton, when you hit reply, it will auto fill the “send to” field with the alias+recipient email address. With mailbox (in my case), it seems to just autofill with the alias only. That is why the email came back to me. I have a hunch that the field they use for autofilling the “send to” is different than the one tuta or proton use.
In tuta, I see the following fields: From, Sender, BCC, and Reply To. I believe mailbox is using the To field, rather than the Reply To field, which is what I assume proton and tuta use.
Do you have the “Use Reply-To Header For Replying” option enabled in your account settings? If so can you try turning that off to see if that makes a difference.
Perhaps Mailbox is not respecting the “Reply-To” header and simply using to “From” header.
One way to narrow it down: open the original forwarded email in mailbox.org, view the full headers, and check what the Reply-To and From headers actually say. If the alias+recipient address is in one of them, the problem is how the client picks the reply target. If it’s in neither, the problem is on the forwarding side. It may also be worth trying the same email in a desktop client like Thunderbird over IMAP, to see whether it’s specific to the webmail.
I disabled the option and that ended up fixing it! Thank you for the suggestion. When I mentioned the issue to them, they were not able to replicate it, so I don’t want to trouble them further. This is good to know though.