Server: Calendar invites: Administrator shall choose if server's or user's email adress is used

Created on 23 May 2017  路  21Comments  路  Source: nextcloud/server

I refer to #2345 and #2778.

If a Nextcloud instance serves for users from different domains (which is the case at least for me), it's annoying that calendar invites are sent with the server's email address instead of the user's once. For me it would be fine if the server's address is taken if there is no user email configured.

To avoid problems with mailservers that might not accept sending emails for more than one domain, this behavior this could be made optional.
(In my case all domains are hosted and handled by one email server and one nextcloud server - I would not like to set up a nextcloud instance per domain).

(If someone is so nice and point me to the place where I can change it in the code myself, would be fine too)

1. to develop enhancement dav

Most helpful comment

to summarise the problem:

  • depending on the environment, users will have email-addresses managed by a different organisation than the Nextcloud-instance. If your Nextcloud is configured with the email address [email protected], but your users use different providers like gmail, outlook, whatever, your email server (abc.tld) can't just start sending out emails for gmail, outlook, etc. Most of the times, these emails will be marked as spam and your server runs the risk of being put onto blacklists for spamming.

... and our options:

  • add an option for admins that allows them to send all emails (or at least emails from the same domain) via the abc.tld email server but with the real user email address. ([email protected]). This should come with a big fat warning that if you enable it despite your users having email addresses from plenty different providers, you might run at the risk of being put onto spam blacklists
  • integrate even better with the mail app. Allow the mail app to hook into the IMipPlugin and send out emails if the currently logged in user has an account registered for the email of the Organizer given in the calendar data. If there is no email registered, fallback to the current behaviour. cc @ChristophWurst

All 21 comments

@tuergeist This is the place to go:
https://github.com/nextcloud/server/blob/master/apps/dav/lib/CalDAV/Schedule/IMipPlugin.php#L109

Feel free to send a PR that implements this optionally. :)

(Message provides a setFrom method, see https://github.com/nextcloud/server/blob/master/lib/private/Mail/Message.php#L81)

Hi @georgehrke, IMHO the problem is the sender's address which I cannot change easily in neither code locations you pointed to. [Or I'm just too stupid]

Aaahh. Got it.

Any news on this?

I'd add that this is an important issue for us at MayFirst.org, who use the same NextCloud across a great many domains and organizational identities. We really need these invitation emails to be coming from the users who send them. Thanks to all who have the capacity and willingness to work on this.

@georgehrke :trumpet: could you update this? :)

cc @jancborchardt This is what we talked about on Talk.

to summarise the problem:

  • depending on the environment, users will have email-addresses managed by a different organisation than the Nextcloud-instance. If your Nextcloud is configured with the email address [email protected], but your users use different providers like gmail, outlook, whatever, your email server (abc.tld) can't just start sending out emails for gmail, outlook, etc. Most of the times, these emails will be marked as spam and your server runs the risk of being put onto blacklists for spamming.

... and our options:

  • add an option for admins that allows them to send all emails (or at least emails from the same domain) via the abc.tld email server but with the real user email address. ([email protected]). This should come with a big fat warning that if you enable it despite your users having email addresses from plenty different providers, you might run at the risk of being put onto spam blacklists
  • integrate even better with the mail app. Allow the mail app to hook into the IMipPlugin and send out emails if the currently logged in user has an account registered for the email of the Organizer given in the calendar data. If there is no email registered, fallback to the current behaviour. cc @ChristophWurst
* integrate even better with the mail app. Allow the mail app to hook into the IMipPlugin and send out emails if the currently logged in user has an account registered for the email of the Organizer given in the calendar data. If there is no email registered, fallback to the current behaviour. cc @ChristophWurst

Sounds like a good idea in general.

Sounds good and seems we should do both options?

Everyone who commented in the thread: Would this solve your issue?

To be sure to understand the proposal of @georgehrke above:

  1. User1, with email address [email protected] will be able to send an invite with his own email address as organizer (and not [email protected] anymore). This has the risk to be considered as spam. This risk is lower if the email address of User1 is [email protected], but the risk still exists.
  2. If User1 configures the mail app with his setup (his credentials + imap.xyz.com for example), the calendar app will be able to send an invite directly from the mail app.

It sounds good :)

Now, what happens if I use Thunderbird for my emails? Will it also work?

I'm super sorry, but all the development power of @ChristophWurst and me are currently bound on other tickets, so this will have to wait for Nextcloud 19.

I'm no dev, but you can get this done by editing nextcloudroot/apps/dav/lib/CalDAV/Schedule/IMipPlugin.php

Change line 255 from:
->setFrom([$fromEMail => $fromName])
to:
->setFrom([$sender => $senderName])

And your invites will come from the email address of the user instead of the server.

@gitterdoneplease this is a bit weird. I'm sure some mail servers will either not allow you to send a message with a mismatching from header or the recipient's mail server will mark it as spam as it looks like someone tries to spoof a sender.

If all users use the same email domain, why should it be blocked?

If all users use the same email domain,

This is something we can't assume. See my comment above:
https://github.com/nextcloud/server/issues/5080#issuecomment-501158303

Dunno gents. I run the mail server too so it鈥檚 not an issue for me. A big warning in the GUI should be enough, but this was necessary in my case to transition completely to NC. Spoofing a from header if you AUTH on a SMTP server is painless, but as pointed out may trigger spam/junk detectors.

So not going to make Nextcloud 19?

I am aware about quite a few organisations with different email domains. This easily happens with mergers, different legal entities for parts of a company (e.g. regulated business vs. un-regulated business, ...). There are tons of situations where this can happen.

Just don't assume that this is always fixed. Adding flexibility does not hurt at all and eases the work of the admins.

I also want to add that even if the mail server / domain is the same, the mail server will not necessarily allow you to send as some.[email protected] with the credentials for the nextcloud notification mail (often something like [email protected]).

Also, since normal non-admin users can usually add and change mail settings via the nextcloud mail app, whether overriding the From header with the notification mail server and credentials will work can even change easily just through a settings change by an unprivileged user!

So I would suggest:

  • have a global check box in the admin panel:

    • [X] Allow sending Calendar Invitations from user mail addresses configured in the Mail app

  • have a check box in the Mail app account settings (maybe disable / grey out this option if the global setting is disabled)

    • [X] Allow NextCloud to send Calendar Invititations from this address

and send out calendar invitations from the user mail address (using the user mail credentials!) only if both settings are enabled.

Was this page helpful?
0 / 5 - 0 ratings