[FIX] tools.mail: ignore original email during encapsulation #79979
Conversation
|
|
|
Shouldn't this be applied to v13 as well as the system parameters exists in that version? |
Certainly yes, though at this point I'm mostly testing the idea ;) It seems GMail does not do this all the time, but only when the mail went through an external domain (e.g. when it displays a |
|
I don't see bad to hide the email address also for privacy questions, so this should be if not always, at least by a configuration option. |
|
And also as strategy: showing your email tempts receivers to take that email and write directly to that one instead of replying and passing through Odoo hub. |
odony
force-pushed
the
14.0-encapsulate-noemail-odo
branch
from
1c9ea1e
to
c260f98
Compare
When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages.
odony
force-pushed
the
14.0-encapsulate-noemail-odo
branch
from
c260f98
to
d9cc4c5
Compare
|
Thanks for the feedback! Removed the cruft, dropped the useless option to keep the old behavior (don't think it's useful indeed), and updated the commit msg/PR desc and tests. I think we can proceed with this small fix if nobody has any blocking issue with it. It will definitely help decrease the risk of being detected as a spam or a tentative spoof by the various email service providers. PS: For the 15.0 port, the logic for triggering the email rewrite is different (based on the |
I chose to only keep the local part of the email instead, e.g if we only have an email |
|
@robodoo r+ please |
When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes #79979 Signed-off-by: Olivier Dony <odo@odoo.com>
|
This pull request has forward-port PRs awaiting action (not merged or closed): #81473 |
3 similar comments
|
This pull request has forward-port PRs awaiting action (not merged or closed): #81473 |
|
This pull request has forward-port PRs awaiting action (not merged or closed): #81473 |
|
This pull request has forward-port PRs awaiting action (not merged or closed): #81473 |
When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes odoo#79979 Signed-off-by: Olivier Dony <odo@odoo.com>
When the system broadcasts an email response to document followers, if the config parameters
mail.force.smtp.fromormail.dynamic.smtp.fromare defined, it will rewrite theFromaddress to avoid spoofing the sender's domain.For example, if the
mail.catchall.domainis set toexample.comand an email response comes from:"John D" <john@doe.com>it will rewrite it to:
"John D (john@doe.com)" <notifications@example.com>This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.)
During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender.
Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course).
This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none.
So after the patch, the rewritten address is now:
"John D" <notifications@example.com>When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages.