[#12678] Incorrect sender address for e-mail notifications
Summary Incorrect sender address for e-mail notifications
Queue Kronolith
Queue Version 4.1.3
Type Bug
State Feedback
Priority 1. Low
Owners
Requester arjen+horde@de-korte.org
Created 2013-09-12 (2200 days ago)
Due
Updated 2016-05-31 (1208 days ago)
Assigned 2016-01-19 (1341 days ago)
Resolved
Milestone
Patch No

Comments
arjen+horde@de-korte.org 2013-09-12 18:40:08
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.

arjen+horde@de-korte.org 2013-09-12 18:44:04
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.

horde@stefanseidel.info 2014-02-11 08:53:27
> When e-mail notifications are used, the sender address will be set 
> to the same value as the recipient address. [...]
> A much better option for setting the sender address would be the 
> default e-mail address of the owner of the calender.

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.

arjen+horde@de-korte.org 2014-02-11 10:03:21
> 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 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 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.

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.

Jan Schneider <jan@horde.org> 2016-01-19 12:25:17
> 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.

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

Jan Schneider <jan@horde.org> 2016-01-19 12:27:55
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.

Jan Schneider <jan@horde.org> 2016-05-27 17:00:19
> 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.
Any opinions on that, anyone?

horde@stefanseidel.info 2016-05-31 06:10:28
>> 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.
> Any opinions on that, anyone?

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.

horde@stefanseidel.info 2016-05-31 06:26:04
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.

arjen+horde@de-korte.org 2016-05-31 07:28:40
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.

Michael Rubinsky <mrubinsk@horde.org> 2016-05-31 12:58:06
> 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.

+1