+1

I agree that this is the only sensible way to deal with this. It does 
open a small window for people to use these notifications for 
spamming, but violation of terms of service should be dealt with by 
disciplinary action (rather than technical means). But this would 
require that somehow the username of the person setting the reminder 
should be logged or be included in the mails.

As far as I know, most if the required stuff is already in place. 
There are $conf[reminder][server_name] and $conf[reminder][from_addr] 
in the Kronolith configuration, the only thing missing is setting a 
SASL password for the sender address.

Should have tested this earlier, but this confirms my suspicion: a 
big? cloud provider sends calendar notifications from 
calendar-notification@theirdomain.com for both internal (on their 
domain) and external addresses - the most sensible choice, really.

Thinking about this again, the $conf[reminder] setting is probably 
crucial. It should be possible to define a fixed sender (+auth), 
because it's not always the case that the user is also a valid email 
sender. I.e. it is possible to have users with email addresses 
external to the Horde server, and in that case sending with that email 
from the Horde server would be wrong and potentially forbidden by SPF 
or other rules.

Is it desirable to try sending the mail without authentication first 
and then use the stored credentials?

Using the default e-mail address of the owner of the calender doesn't 
really change the situation here I think, because how can it be 
ensured that _this_ address can be used for sending mail without 
authentication?

The only other solution I could think of would be to let the users 
decide how to send emails "in their name" when they are not logged in, 
potentially requiring them to save their mail credentials in the 
settings. I don't think we want to go down that route?

Since I'm also interested in making this work for me, I could take a 
look at the $conf[reminder] settings and see how to make them work if 
noone else is already planning to work on this.

Any opinions on that, anyone?

I'm still pondering whether it's not some kind of anti-spam protection 
to use the recipient as the sender, so that you are only able to send 
notifications if your authorized to do so.

Those are used by the daily agenda script kronolith-agenda.

The sender address may be an option when sending reminders manually 
through Kronolith, but this won't work for automatic notifications. 
These will run through Horde_Alarm, which probably won't have the SMTP 
AUTH credentials for the owner of the calendar and may not have any 
SMTP AUTH credentials at all.
The latter is supposedly (almost) possible, through the 
$conf[reminder][server_name] and $conf[reminder][from_addr] in the 
Kronolith configuration. But since there is no way to set a password, 
this will not work for systems that require SMTP authentication.

I couldn't find where the $conf[reminder][from_addr] from the 
Kronolith configuration is used anyway, so this may be a feature that 
is not fully implemented yet.

This is actually correct. Since the user is adding a sender address, 
he/she must also be authorized to actually send from this address. The 
real solution to this problem would be to either allow the sender 
address, or to allow to enter additional SMTP host/port/credentials to 
make Horde send through the correct mail server with the correct 
authentication.

And to make matters even worse, Kronolith doesn't pick up the 553 
response from the mailserver either and will continue to attempt to 
send notifications. To the point that the mailserver starts 
blacklisting the sender for excessive connection errors.

When e-mail notifications are used, the sender address will be set to 
the same value as the recipient address. This is not a problem if the 
(optional) e-mail address to be used is left blank. But if one uses a 
different address, this fails if either the sending mailserver Horde 
uses verifies if a user is allowed to use an address or if the 
recipients mailserver does SPF checking for instance and the 
recipients domain is restrictive.

My mailserver checks if senders are allowed to use an address and the 
following shows up in the mailserver logs when I attempt to send 
notifications to 'whoever@example.com':

2013-09-12T15:20:00.821854+02:00 mail postfix/smtpd[7360]: Anonymous 
TLS connection established from localhost[127.0.0.1]: TLSv1 with 
cipher ECDHE-RSA-AES256-SHA (256/256 bits)
2013-09-12T15:20:00.858909+02:00 mail postfix/smtpd[7360]: NOQUEUE: 
reject: RCPT from localhost[127.0.0.1]: 553 5.7.1 
<whoever@example.com>: Sender address rejected: not owned by user 
arjen; from=<whoever@example.com> to=<whoever@example.com> proto=ESMTP 
helo=<mail.de-korte.org>
2013-09-12T15:20:00.907869+02:00 mail dovecot: imap-login: Login: 
user=<arjen>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=7445, 
secured, session=<1mJcmC/m6gB/AAAB>

A much better option for setting the sender address would be the 
default e-mail address of the owner of the calender.