Notifications sent to all users

[Ben Gamari]

Recently ​GHC upgraded its Trac installation to Trac 1.2 and AccountManagerPlugin HEAD (r16056). This installation has smtp_always_cc = ghc-tickets@haskell.org set in the [notification] section of trac.ini. Since the upgrade password reset and email verification messages have been getting sent to ghc-tickets@haskell.org, in addition to the intended recipient.

A bit of debug output added to SingleUserNotification.get_smtp_address reveals that get_smtp_address is only called for the intended recipient, suggested that the ghc-tickets address is only added later in the notification pipeline.

[Ben Gamari]

Bumping priority since this exposes user passwords to a public mailing list.

[Ryan J Ollos]

Please share your [account-manager] settings from trac.ini with any sensitive configuration info obfuscated.

[Ben Gamari]

Here it is,

[account-manager]
account_changes_notify_addresses =
authentication_url =
db_htdigest_realm =
db_htpasswd_hash_type = md5
force_change_passwd = false
force_passwd_change = enabled
hash_method = HtPasswdHashMethod
htdigest_file =
htdigest_realm =
htpasswd_file = /home/trac/ghc/trac.htpasswd
htpasswd_hash_type = md5
notify_actions =
password_format = htpasswd
password_store = SessionStore
persistent_sessions = enabled
refresh_passwd = disabled
register_check = BasicCheck,EmailCheck,BotTrapCheck,RegExpCheck,RegistrationFilterAdapter,UsernamePermCheck
reset_password = enabled
username_regexp = (?i)^[A-Z0-9.\-_]{3,}$
verify_email = enabled

[Ben Gamari]

Has there been any motion on this, Ryan?

[Ryan J Ollos]

I will take a look at it soon. ​PatchWelcome.

[Peter Suter]

(Similar issue in the old NotifyEmail system: #8796.)

From: ​t:comment:8:ticket:5670:

2. smtp_always_bcc and smtp_always_cc

Does always mean all emails or all ticket notification emails?

With NotifyEmail it meant all emails and plugins had no good way to opt-out.

In the new system AlwaysEmailSubscriber (since #11934) implements these and still forwards all emails. Plugins probably now have enough flexibility to deal with this. (e.g. higher priority subscriptions, disabled components, using distributors directly...)

Apparently #8796 did find a way to opt-out in the old NotifyEmail system.

Looks like AccountManagerPlugin currently​ relies on the deprecated NotifyEmail compatibility shims, where this workaround doesn't work. So this entire subsystem should be rewritten using the Trac 1.2 API. Then I guess a custom subscriber could provide a default subscription with priority 0 and adverb never for account notifications. (But AlwaysEmailSubscriber also has priority 0!) Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

I would in any case recommend not using smtp_always_cc if you don't want all emails to be CC'd there.

[Ben Gamari]

I would in any case recommend not using smtp_always_cc if you don't want all emails to be CC'd there.

Fair enough. We are using smtp_always_cc for our ghc-tickets mailing list, which receives all ticket traffic. While I wasn't around when this was configured, I suspect that the motivation for this was taken from the ​wiki:TracNotification page.

What is the recommended way to consolidate ticket traffic to a mailing list under Trac 1.2?

[Peter Suter]

Please try ​t:wiki:CookBook/Notification/Subscriptions#Subscribetoallticketnotifications.

[Ryan J Ollos]

​trac:#11871 will also add an AllTicketsSubscriber, so individual users can subscribe to all ticket changes. The difference in contrast to the recipe in comment:10, as far as I can tell, is that a user can configure the behavior for the account, whereas TicketAlwaysEmailSubscriber allows the administrator to configure the behavior.

Assuming you have a workaround, I'm closing this and will focus on #13124. Unfortunately I hardly have time to keep this important plugin working, but hope to eventually have a version that works well with Trac 1.2.

[Ryan J Ollos]

Replying to Peter Suter:

Then I guess a custom subscriber could provide a default subscription with priority 0 and adverb never for account notifications. (But AlwaysEmailSubscriber also has priority 0!) Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

Is the idea that we can filter out AlwaysEmailSubscriber from NotificationSystem.subscriptions before calling distribute_event?

[Peter Suter]

a custom subscriber could provide a default subscription with priority 0 and adverb never for account notifications.

This approach would try to get NotificationSystem.subscriptions itself to ​drop the subscriptions by AlwaysEmailSubscriber by adding never "unsubscriptions" of higher priority.

(But AlwaysEmailSubscriber also has priority 0!)

I'm not sure if it's allowed to have higher priority (lower number) than ​priority 0, i.e. negative priority. It seems zero is already questionable according to ​this documentation:

priority: An integer priority. Smaller numbers have higher priority than bigger numbers. 1 is the highest priority.

I don't remember why (I thought) this is the case.

---

Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

This alternative approach would not use NotificationSystem.subscriptions at all, based on the assumption that "normal subscriptions" are irrelevant e.g. to a password reset event, where Account Manager must send email to (and only to) the current user:

nsys = NotificationSystem(self.env)
special_current_user_subscription = (current_user_sid, current_user_auth, current_user_addr, 'email', 'text/plain')
subscriptions = [special_current_user_subscription]   # instead of nsys.subscriptions
nsys.distribute_event(event, subscriptions)   # instead of nsys.notify(event)

This shuts out flexible subscriber plugins configurable by users and admins from influencing the behavior. Instead the behavior is more hardcoded = predictable = reliable = secure.

[Peter Suter]

Yet ​another approach would just change AlwaysEmailSubscriber itself, so it can be configured to ignore certain realms.

---

One more alternative is to disable AlwaysEmailSubscriber entirely and use e.g. ​TicketAlwaysEmailSubscriber instead, which only CC's the mailing list for the ticket realm.

[Ryan J Ollos]

Replying to Peter Suter:

Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

This alternative approach would not use NotificationSystem.subscriptions at all, based on the assumption that "normal subscriptions" are irrelevant e.g. to a password reset event, where Account Manager must send email to (and only to) the current user:

nsys = NotificationSystem(self.env)
special_current_user_subscription = (current_user_sid, current_user_auth, current_user_addr, 'email', 'text/plain')
subscriptions = [special_current_user_subscription]   # instead of nsys.subscriptions
nsys.distribute_event(event, subscriptions)   # instead of nsys.notify(event)

This shuts out flexible subscriber plugins configurable by users and admins from influencing the behavior. Instead the behavior is more hardcoded = predictable = reliable = secure.

This sounds good. I will give it a try. I seems like the preferable approach since we don't have permissions for subscribers.

[Ryan J Ollos]

Replying to Peter Suter:

Yet ​another approach would just change AlwaysEmailSubscriber itself, so it can be configured to ignore certain realms.

That looks like it would be useful to implement in Trac 1.5.x. I might try implementing if I find time.

I think the implementation in r17492 went well following your suggestions. Thanks!