New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FW][FIX] tools.mail: ignore original email during encapsulation #81807
Closed
fw-bot
wants to merge
1
commit into
odoo:master
from
odoo-dev:master-14.0-encapsulate-noemail-odo-eHVd-fw
Closed
[FW][FIX] tools.mail: ignore original email during encapsulation #81807
fw-bot
wants to merge
1
commit into
odoo:master
from
odoo-dev:master-14.0-encapsulate-noemail-odo-eHVd-fw
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
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: 3c65ec5
Ping @odony To merge the full chain, say
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
@fw-bot r+ |
robodoo
pushed a commit
that referenced
this pull request
Dec 22, 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 #81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com>
std-odoo
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 22, 2022
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#81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com>
std-odoo
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 23, 2022
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#81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Mar 25, 2022
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 #81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: #87040
std-odoo
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 25, 2022
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#81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Mar 25, 2022
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 #81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: #87261
std-odoo
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 25, 2022
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#81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com>
std-odoo
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Mar 29, 2022
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#81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Mar 29, 2022
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 #81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: #87294
robodoo
pushed a commit
that referenced
this pull request
Mar 29, 2022
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 #81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: #87294
cormaza
pushed a commit
to cormaza/odoo
that referenced
this pull request
Jul 15, 2022
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#81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: odoo#87294
gustotc
pushed a commit
to multidadosti-erp/odoo
that referenced
this pull request
Nov 24, 2022
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#81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: odoo#87040
gustotc
pushed a commit
to multidadosti-erp/odoo
that referenced
this pull request
Dec 13, 2022
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#81807 X-original-commit: 3c65ec5 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: odoo#87040
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Jan 11, 2023
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/odoo#81807 X-original-commit: 3c390c4810136a0fb8b54ba0456ad2a75d2450c1 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: odoo/odoo#87294
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.from
ormail.dynamic.smtp.from
are defined, it will rewrite theFrom
address to avoid spoofing the sender's domain.For example, if the
mail.catchall.domain
is set toexample.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.
Forward-Port-Of: #81473
Forward-Port-Of: #79979