[FW][FIX] tools.mail: ignore original email during encapsulation #81473
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
Ping @odony cherrypicking of pull request #79979 failed. stderr: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?). In the former case, you may want to edit this PR message as well. |
robodoo
added
conflict
odony
force-pushed
the
15.0-14.0-encapsulate-noemail-odo-oKks-fw
branch
from
819b5b0
to
bcd3233
Compare
odony
force-pushed
the
15.0-14.0-encapsulate-noemail-odo-oKks-fw
branch
from
bcd3233
to
f70a142
Compare
odony
force-pushed
the
15.0-14.0-encapsulate-noemail-odo-oKks-fw
branch
from
f70a142
to
a9cf4a4
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. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. 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. X-original-commit: 2297302
odony
force-pushed
the
15.0-14.0-encapsulate-noemail-odo-oKks-fw
branch
from
a9cf4a4
to
c242d99
Compare
|
@robodoo r+ please |
This was referenced Dec 22, 2021
duyphongdn1997
pushed a commit
to duyphongdn1997/odoo
that referenced
this pull request
Dec 24, 2021
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. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. 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#81473 X-original-commit: 2297302 Signed-off-by: Olivier Dony <odo@odoo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Forward-Port-Of: #79979