#2434 closed enhancement (fixed)
Separate emails sent for each recipient
Reported by: | Owned by: | Emmanuel Blot | |
---|---|---|---|
Priority: | normal | Milestone: | 0.10 |
Component: | ticket system | Version: | 0.9 |
Severity: | normal | Keywords: | notification email |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Trac sends out separate emails for each recipient which meant that putting email aliases in the CC field could mean people would get duplicate messages. If all the addresses were placed in the To and Cc fields then email servers could weed out duplicates in the standard way.
Attachments (0)
Change History (10)
comment:1 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 19 years ago
Just a note: While this is as much as Trac can do, it may not address the issue of multiple emails going to users that are both addressed directly and are members of an alias. Some mail systems may handle this gracefully, but I now realize that at least our email server, Lotus Notes, is only able to weed out duplicates sent from within Notes. It appears that outside emails are always sent to all recipients, even if they are already receiving a copy as members of an alias.
comment:3 by , 19 years ago
Cc: | added |
---|
It would be better to collect all mail addresses for notification and remove duplicates from that list before sending notifications.
I prefere one mail per recipient and not putting everybody on CC/TO. Please not that this is also problematic from a data privacy point of view in some countries (eg. Germany). Mailinglisst or systems sending out mail to multiple recipients must ensure that recipients can't see who got this mail too.
comment:5 by , 19 years ago
Keywords: | notification email added |
---|
This issue is addressed up to some level in the notification sandbox.
There is a configuration option to either send the CC list as Cc:
or Bcc:
(to fulfill the privacy requirement). Duplicates are also removed (as long as they appear with the exact same syntax, no alias resolution is done here) before emails are sent.
I do not think one mail / recipient is a good idea, as notifications are processed synchronoulsy within the web request: the web server sends the next page once the communication with the SMTP server is complete. The current implementation uses one SMTP connection per recipient. Although this might be optimized, I think it is preferable to send one email for all recipients - there may be a flaw here if the list of recipients is very long, but I think this could be addressed in a second step.
comment:6 by , 19 years ago
There is a configuration option to either send the CC list as
Cc:
orBcc:
(to fulfill the privacy requirement)
What's contained in the To:
header?
comment:7 by , 19 years ago
To:
reporter, owner (as long as I remember)
To:
is always visible whatever the Cc
/Bcc
setting.
comment:8 by , 19 years ago
Milestone: | → 0.10 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Should be fixed in [2799]
comment:10 by , 18 years ago
Cc: | removed |
---|
Note: sandbox/notification [2598] implements this feature