Actually this seem to be fixed in Horde's side for version 3.1.4 and 3.1.5.

So never mind the previous comment, upgrading Horde to newest fixes

the issue.

I believe this is the same issue i have encountered, so i request this 
ticket to be re-opened. The issue exists in versions 4.1.4 and 4.1.5 
as well.



The problem is that when the notification is sent the mail address

is fetched with horde's Identity->getDefaultFromAdress() function:



attachment.php, around line 90:

$mail_address = $mail_identity->getDefaultFromAddress();



Now, this works perfectly fine when the user who sent the email actually has

a from-address saved to default identity, but when it's empty we run 
into problems.



It's quite common that there's no from address in default identity 
when for example the username is the same as the email address that is 
used and so ie. compose-page is able to parse it from there already.



When the one downloading the link is not logged in to horde (ie. is an 
outside user reading the email somewhere else) this leads to the fact 
that the notifications are sent to addresses like

  'Firstname Lastname <"\"\""@hordes_domain.tld>'

and they get bounced to mailer-daemon.



So if you're the postmaster you will get quite annoyed by all those 
notifications and that's why actually started to debug this issue.



It looks like there was an attempt to fix this in 4.1.4 and 4.1.5, i 
haven't tested if it works, but i doubt it, because at least in my 
case the returned address is not just <> but <"\"\""@hordes_domain.tld>.





The bigger problem, actually a small security issue, happens when the 
first one downloading the link does it through the same 
horde/imp-system.



This is because when the form-address in the default identity is 
empty, getDefaultFromAddress() does this:

         if (empty($addr)) {

             $addr = Auth::getAuth();

         }



As the result, the address of the user downloading the link is returned

and the notification is sent there allowing this user to permanently

delete the linked attachment.



My suggestion is that when the from-address in default identity is 
empty, the email address should be constructed from the username 
(which we get from the link) or the username and the default domain 
(if there's no @ in username). As the username is also used to get the 
attachment's name, and attachment's existence is checked before, i 
don't see any risk in doing so.

I can't reproduce this. There have been a couple of fixes around 
linked attachment notifications in the general timeline of those 
releases, though. It's possible you're missing one of them somehow 
with your customizations.

we are using Horde 3.1.3 whith a freshly updated IMP 4.1.3. The Horde 
authentication is handled by IMP; the preference backend is SQL.



Since this update, if a user sends a mail with a linked attachement, 
and the recipient reads the mail and retrieves the attachment from the 
same Horde server as the sender used to send the mail, the "linked 
attachment downloaded" notification gets sent to the recipient instead 
of the sender !



This does not occur if the recipient retrieves the attachement from 
another mail client (i.e. without being logged in to the Horde server).



This behaviour seems to be related to the code which retrieves the 
DefaultFromAddress from the sender's preferences and identities in 
attachment.php.

It looks like the Prefs::singleton and/or Identity::singleton 
functions calls get confused when called from within an authenticated 
session, and return the authenticated user's parameters instead of the 
requested one's.



Since our Horde setup is quite heavily customized, we can't be sure 
whether this behaviour is caused by our particular setup or is 
inherent to Horde. Could someone verify this point using a generic 
Horde/IMP setup ?