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.
closesodoo/odoo#81807
X-original-commit: 3c65ec5a8191a392980ceb0a8c584767eae405f1
Signed-off-by: Olivier Dony <odo@odoo.com>
RATIONALE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Purpose is to prepare future changes by easing its grep. Notification is too
much heavily used through the codebase and finding it was quite hard among
other noise.
Rename ``notification`` field to ``is_notification``.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Be aligned with mail_mail model naming as well as convention used in SMS
application (sms_sms_id, sms_sms_int) and mass mailing application (using
mail_mail_id on mailing.trace model).
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
=======
We want to increase the score of the emails sent by Odoo and we want to
avoid them to be marked as spam by the mail clients (gmail, outook...).
SPECIFICATIONS
===============
From filter
-----------
Add a new field on the "ir.mail_server" which is "from_filter". This
field defines the email address for which the outgoing email server can
be used.
The "from_filter" can either define an email address or a domain name.
Use the system parameter "mail.default.from" which allow us to define
a default email address which is used to encapsulate the emails
(default: notifications@<catch.all.domain>).
Mail server priorities
----------------------
When sending an email, we read the FROM header and,
- We first look for a mail server which match the entire mail FROM
in that case, we do not change the email header (not needed)
- If not found, we search a mail server which matches the domain name of
the mail from (do not need to change the headers in that case)
- If not found, find the mail server linked to the "notifications"
email (defined in the system parameter). Then change the FROM header
to the notification email, and put the old one in the name part of
this header.
E.g.
Initial mail from: "Admin" < admin@example.com >
Final mail from: "Admin (admin@odoo.com)" < notifications@odoo.com >
- If no notification email is configured or if no mail server are
found for the notification email, fallback to the old system and
spoof the FROM header. In that case we do not have the choice if we
want to send the email, he will probably be marked as spam.
Sending method priority
-----------------------
In the mail server models, we defined some priorities,
1. Forced SMTP session
2. Forced mail server
3. Try to find the best mail server (see "Mail server priorities")
4. If not found, read the odoo-bin arguments
Bounce
------
As there's no standard for bounce address, we put it in the envelope
(smtp_from). But in some case, it might be considered as spoofing. So,
we use the bounce address ONLY if the mail server is configured for the
entire domain name.
One behavior which might be broken is the following; we send an email as
"std@gmail.com" and the bounce address is on the domain "odoo.com".
Before we received the bounce notifications but we were spoofing the
local part and the domain.
Now
- if a mail server is configured for GMAIL, we do not use the bounce
address (and we might not receive the bounce notification)
- if no mail server is configured for GMAIL, but one is configured for
"odoo.com"
- the FROM header will be "notifications@odoo.com"
- the FROM envelope will be the bounce address
=> In this situation we are spoofing only the local part of the email
but it's allowed as the mail server is configured for the entire
domain name
LINKS
=====
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
Starting from this commit bounce addresses set in emails will not use any
plus addressing. They will always be ``bounce_alias#@alias_domain`` and
not ``bounce_alias+<mail_id>-<mail_model>-<mail_res_id>@alias_domain``.
Reasons are
* this plus addressing adds information we do not use anymore since a long
time as bounced messages are found using their message ID and not any
information coming from this bounce address;
* this generates unnecessary noise;
* not all email providers really support plus addressing as a mean to
generate "fake" additional email addresses;
This is the followup of odoo/odoo#71244 where a solution to avoid plus
addressing was done in table. We can now safely remove this feature in
master as a cleaning step.
Task ID-2577328
closesodoo/odoo#73363
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since odoo/odoo@f4524f03c3 plus addressing is not used anymore
for handling bounces. Indeed it relies on references / in reply to to find
original message that bounced. It is therefore not necessary to enforce the
use of plus addressing.
As some provider do not support plus addressing as a way to contact left-part
of email with sub-informations people should have a way to deactivate plus
addressing used in bounce aliases.
To preserve backwards compatibility for stable versions old behavior is
retained unless a new `mail.bounce.alias.static` ICP is set with a truthy
value.
Fix https://github.com/odoo/odoo/issues/71242 by dropping requirement of plus addressing.
@Tecnativa TT29827
Closes#71242
Task ID-2547347
PR odoo/odoo#72347
X-original-commit: df2d955bf41b01556e1b84bb1204aac045c95a63
RATIONALE
A bit of history. Link between a message and its recipients has been added
at first mail refactoring towards a Chatter / Discuss feature. It was done
in v7 at d64f3c9783 with the base addition of mail notification model (lots
of commits follow that one but that's the first one about notification).
Due to some people thinking that it was unnecessary to keep a model for
notification it has been removed in v9 at 88b8cd0587. Notification table was
renamed from mail_notification to mail_message_res_partner_needaction_rel.
It was proven to be a mistake even if those "some people" were warned and
model made its way back to Odoo in v10 at 72dfcae2a4 . Table name mail_message
_res_partner_needaction_rel was kept to ease migration and backward
compatibility.
It is now time to complete the circle and rename it to mail_notification.
SPECIFICATIONS
Rename ``mail_message_res_partner_needaction_rel`` to ``mail_notification`` .
RIP JEM.
Never forget.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This reverts commit 976e560a87.
Even if it didn't looked like a bad idea, this need some more thinking.
This new version of query count creates random failure of runbot builds.
closesodoo/odoo#43820
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- take advantage of runbot multi-build capabilities
- get similar result when running them locally during dev
- better detect when other modules add extra queries
Query counts are split in the base value (testing with just test_mail installed)
+ the extra modules overhead.
Part of task-2178641
closes odoo/odoo#43666
Pr: #43666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test_mail_followers, test_mail_mail,
test_mail_template.
LINKS
Task ID 2068986
PR #38070
A patched method was not unpatched. Which triggered issues in a staging
master branch trying to untie a bit mail tests.
closesodoo/odoo#40099
X-original-commit: 5dbf4c56765c3661eb2dca24e90bc0b420918e9a
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Quickly clean common class and lessen data creation by default. Offer some
tool methods, notably to create portal users used in some tests but not
all, or to create mail templates.
LINKS
Task 1958697
This is related to revision
71f188082f
This is nice to have a meaningful explanation
for the user to understand why his mail is not sent,
this is better to not interrupt the mail queue when doing so.
Because of the above revision,
when the mail queue iterated on a mail failing because
of an ASCII encoding issue,
the mail queue was interrupted,
and on the next cron call it failed again and again
on the same mail, therefore leading to the mail queue
to never be processed.
Fixes#27804
Purpose of this commit is to use the newly introduced helper to create
test users in a quick way and reduce code duplication. A mail specific
helper tool function is defined based on the standard one defined in test
allowing to pass a custom context. It bypasses mailing features in order
to speedup the creation.
This commit is linked to task ID 1889703 and PR #27526.
Sending email to addresses containing unicode characters
cannot be parsed by python and result in a UnicodeEncodeError.
This PR catch that specific exception and output a meaningful
error message.
Decision has been taken to not trigger any error message
client-side has it would have needed modifications on some
sensitive low-level backend code.
To reproduce:
- Configure odoo so it uses an email server
- Send an invoice to a partner whoose email address contains
some unicode characters (exemple: æøåÇÀ@example.com)
opw-1892409
closesodoo/odoo#27804
Olivier Dony