6.0.0-git
2018-12-16

[#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 (at) de-korte (dot) org
Created 2013-09-12 (1921 days ago)
Due
Updated 2016-05-31 (929 days ago)
Assigned 2016-01-19 (1062 days ago)
Resolved
Milestone
Patch No

History
2016-05-31 12:58:06 Michael Rubinsky Comment #11 Reply to this comment
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
2016-05-31 07:28:40 arjen+horde (at) de-korte (dot) org Comment #10 Reply to this comment
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.
2016-05-31 06:26:04 horde (at) stefanseidel (dot) info Comment #9 Reply to this comment
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.
2016-05-31 06:10:28 horde (at) stefanseidel (dot) info Comment #8 Reply to this comment
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.
2016-05-27 17:00:19 Jan Schneider Comment #7 Reply to this comment
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?
2016-01-19 12:27:55 Jan Schneider Comment #6
State ⇒ Feedback
Reply to this comment
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.
2016-01-19 12:25:17 Jan Schneider Comment #5 Reply to this comment

[Show Quoted Text - 9 lines]
Those are used by the daily agenda script kronolith-agenda.
2014-02-11 10:03:21 arjen+horde (at) de-korte (dot) org Comment #4 Reply to this comment
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.
2014-02-11 08:53:27 horde (at) stefanseidel (dot) info Comment #3 Reply to this comment
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.
2013-09-12 18:44:04 arjen+horde (at) de-korte (dot) org Comment #2 Reply to this comment
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.
2013-09-12 18:40:08 arjen+horde (at) de-korte (dot) org Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Incorrect sender address for e-mail notifications
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
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.

Saved Queries