Dependency Graph

Dependency Graph
related to related to child of child of duplicate of duplicate of

View Issue Details

IDProjectCategoryView StatusLast Update
0005565SOGoBackend Calendarpublic2023-02-20 17:55
ReporterChristian Mack Assigned Tosebastien  
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Product Version5.7.0 
Fixed in Version5.8.1 
Summary0005565: Sending event invitations (iMIP) with mailAlarms.creds auth instead of user creds auth
Description

User A shares one of his calendars with user B and gives her/him modify and/or creation and/or deletion privileges on it.
When user B creates/modifies/deletes an event with invitations in A's shares calendar, an email is send to all invitees (= iMIP).
That email informs the invitees about the change made to that event.
For invitees not part of the same SOGo server, those emails are the only way to get notified about such a change.
Therefore those emails are essential.

This email is sent with user B's credentials, as she/he has made the change.
But that email has a FROM containing user A's email address as owner of that calendar and therefore that event.
That is correct, as accepting/denying that event by the invitees must go back to A.

But as this address does not belong to user B, our email system is denying that email.
Currently we have to manually set exception rules for user B, to be allowed to send emails with FROM address of A.
That is a security risk, as user B can send now any email in the name of A.
This is also a hassle and error prone manual workaround.

Therefore it would be better, if such system emails would be send via the same account used for email alarms already.
That account is already able to send as any user and SOGo knows and uses it already.

Steps To Reproduce
  • User A creates calendar "delegated events"
  • User A shares that calendar with user B
  • User A gives modify and create and delete privileges to user B
  • User A creates an event and invites user C and an external person D
    => invitation emails are send to C and D
  • event is added to C's personal calendar in same SOGo server
    All is OK
  • User B changes that event
    => change emails are dropped, because B is not allowed to send as A
  • event is changed in C's personal calendar
    => !! D does not get notified at all, and C only sees that change in her/his personal calendar (which is in reality often missed). !!
Additional Information

As this changes email delivery for those iMIP event emails, I assume it would be better to have a new option on domain level to switch that behaviour.

I am aware, that some setups don't use email alarms.
But those who do, have less to setup when those credentials can be used for all emails created by the SOGo system.

Emails created by users still have to be send as that user.

TagsNo tags attached.

Relationships

related to 0005605 new No invitation will be sent if created in a shared calendar 

Activities

francis

francis

2022-08-03 21:19

administrator   ~0016150

We could add a new option to the domain default SOGoSMTPAuthenticationType. Maybe something like plain:<username>:<password>. Notice that neither the username nor the password should contain colons. This is currently a limitation of sogo-ealarms-notify (SOGoCredentialsFile) as well.

I suggest to modify SOGoMailer.m to check if the sender address is associated to the context user. If it's not, we use the provided "super" credentials.

Christian Mack

Christian Mack

2022-08-04 11:23

developer   ~0016151

If sending with "super" credentials only happens for SOGo generated system messages and not for user generated emails, then this is OK with me.

sebastien

sebastien

2023-02-20 17:55

administrator   ~0016668

Documentation : https://github.com/Alinto/sogo/blob/master/Documentation/SOGoInstallationGuide.asciidoc#smtp-server-configuration

Commits :

Issue History

Date Modified Username Field Change
2022-08-03 07:53 Christian Mack New Issue
2022-08-03 21:19 francis Note Added: 0016150
2022-08-04 11:23 Christian Mack Note Added: 0016151
2022-09-22 09:43 Christian Mack Relationship added related to 0005605
2023-02-20 17:55 sebastien Note Added: 0016668
2023-02-20 17:55 sebastien Assigned To => sebastien
2023-02-20 17:55 sebastien Status new => resolved
2023-02-20 17:55 sebastien Resolution open => fixed
2023-02-20 17:55 sebastien Fixed in Version => 5.8.1