English
Chinese (Simplified)
French
German
Italian
Japanese
Russian
Spanish
Vietnamese
Outlook adding my email address to 'Reply All'
-
Since upgrading to MDv25, my users are reporting that their email addresses are added to 'Reply All'. More of a nuisance than anything, but I'm sure the ancient version we've been runing never did that.
Ideas?
-
What version of Outlook are you using?
Is the user the original sender of the message? Is the user's address in the To or CC headers of the email?
Can you upload a sample MSG file that can be used to reproduce the issue and let us know the email address of the user that is having the issue?
-
Hi Arron, we're using a mix of Office 2024 and 2021. Yes, the user is the original sender and is placed in the To header.
I thought it might have just been Outlook, but since the same behaviour occurs in Webmail I now suspect it has something to do with Header Translation settings in the new MD. It's happening with all our users.
How do I upload to you? I'm not seeing a link for that on this forum
-
Sorry, I forgot to provide the link.
https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6
Please let me know the name of the file you upload.
-
Thanks, Arron. I've uploaded "Re: Test.msg"
-
I do not see the MSG file, can you upload it again?
-
@Arron done. If there's anything else you need, please let me know
-
Sorry, I should have been more specific. That appears to be a message exported via Outlook, which doesn't actually let me see the RFC822 message headers and body. Can I get the MSG file for a test messag that has the issue from the user's mailbox directory on the server?
-
@Arron my fault entirely. 🙃 Uploaded now.
-
Do you have the mailboxes configured on a subdomain?
If you have a mailbox setup for user@sub.domain.com and messages for user@domain.com are routed to the mailbox, you can have this happen. Typically a client removes its own address from the list of recipients when you use reply all. If the client is using user@sub.domain.com but the message was sent to user@domain.com, then when reply all is used, the client doesn't find its address (user@sub.domain.com) in the list of recipeints so it includes them all in the response.
If I setup an account in MDaemon for user@domain.com and create an alias so that user@domain.com = user@sub.domain.com. Then send an email to user@domain.com from another local account. When I go into webmail and choose reply all, you will notice that only the sender is in the To field. If you open the same message in Outlook and click reply all, you will notice that both the sender and user@domain.com are in the list of recipients. In my example, this is occurring because webmail is aware of the alias, Outlook is not.
-
Do you have the mailboxes configured on a subdomain?
Yes, we do.
In setting up our Outlook clients to use MDv25, I noticed that the "Email Address" field must be user@sub.domain.com to be able to send a test email, but using the old MDv10 the "Email Address" field could be different (eg. user@domain.com) to the "User Name". I presume this is enforced now to improved security.. but it could also just be a setting I've missed?
We already have "@sub.domain.com = @domain.com" in Header Translation
Is it possible to set an alias so that user@sub.domain.com = user@domain.com? Where would I do that?
-
Header translation only changes the headers on outbound emails.
I see a couple of different options. You can change the email address configured in Outlook so that it uses user@sub.domain.com as the From header and allow header translation change it to user@domain.com.
You could change MDaemon's domain to domain.com, remove header translation configurations and leave all clients configured to use user@domain.com. If you still need sub.domain.com to work, create an alias for *@sub.domain.com = *@domain.com. Since all clients are using domain.com in their email address it should correct the issue.
You could use the content filter to search and replace sub.domain.com with domain.com on inbound emails.
There are a lot of potential implications with any of these changes so I can't tell you which one you should use, but I'm happy to provide more information if you need it.
Without any knowledge of the situation and why you have MDaemon configured this way, I'd suggest changing MDaemon to use domain.com as the domain name would be the best solution. It will most likely be the easiest to manage going forward as it simplifies configurations.
-
Thanks, Arron!
Without any knowledge of the situation and why you have MDaemon configured this way, I'd suggest changing MDaemon to use domain.com as the domain name would be the best solution. It will most likely be the easiest to manage going forward as it simplifies configurations.
We configured it that way +20 years ago to avoid potential clashes/issues pulling email from our real "domain.com" out there in the cloud.
How does MD behave in this space? Will I 'break the Internet' if I change our MD domain settings from sub.domain.com to domain.com??
-
You will not break the internet. MDaemon will do just fine.
Before changing the domain in MDaemon, I'd verify DNS for domain.com. Make sure your MX, SPF, DKIM, and DMARC records are configured as expected. Remove the *@domain.com = *@sub.domain.com alias in MDaemon as well as the header translation configuration. Then rename the domain in MDaemon. This will update the accounts, public folders, and mailing lists. Add a new alias for *@sub.domain.com = *@domain.com in case anybody sends to the sub domain. Then you'll have to update all of the email clients to use @domain.com as their email address instead of @sub.domain.com. Update any content filter rules you are using to make sure they are looking for @domain.com instead of @sub.domain.com.
If any users have IMAP filtering rules that are filtering using the domain, they will need to be updated too.
There may be other items I'm not thinking of. I would test to make sure outboud email looks as expected when received by a third party domain, and that replies are coming into the server. Then watch the logs for issues and make adjustments as needed.
While you are making changes on the clients, I'd seriously consider having all clients send to MDaemon on port 587 instead of 25 or 465. This will require they authenticate and they should also use STARTTLS to encrypt the communication.
