View Issue Details

IDProjectCategoryView StatusLast Update
0004495SOGoWeb Mailpublic2018-08-15 14:30
Reporterisibaar Assigned Tofrancis  
Status resolvedResolutionfixed 
Platform[Server] LinuxOSRHEL/CentOSOS Version7
Product Version4.0.0 
Fixed in Version4.0.2 
Summary0004495: When replying, the correct sender alias is not chosen automatically

When replying to a message, the "send from" dropdown has always the primary email address selected even if the e-mail the user is trying to reply to was originally sent to one of the other identities of the user (either alias email or delegated identity).

When composing a reply, by default the sender identity matching the original message that's replied to should be pre-selected from the sender address dropdown.

Steps To Reproduce

Add an alias email address to a user's account (or delegate some other user's sender identity). Then send an email with the "To" field set to this new alias email address (and make sure it's delivered into this user's account). Open the email, click the "reply to" icon. The compose email window opens up and has the "To" address set to the original sender's email address BUT the "From" dropdown has the user's primary email address chosen and NOT the alias address to which the email the user wants to respond to was originally sent to.

Additional Information

Automatically choosing the right sender email address from the available alias emails in the dropdown seems like a very basic functionality. Every other webmailer I know of does this as expected.

It would seem extremely tedious that a user first needs to check what the original email address was to which the message the user wants to reply to was originally sent to and then needs to manually choose this address from the dropdown of available alias email address every time sending a reply. And omitting to choose the matching sender identity when replying could also lead to very undesired situations. So I consider this a bug.

TagsNo tags attached.




2018-07-18 17:43

reporter   ~0012965

Thanks for the patch! I've installed SOGo 4.0.1 today and it's indeed a lot improved now but unfortunately the behavior is not yet fully ideal.

It seems the right sender identity gets not automatically selected when the "To" field contains only an email address but no name. E.g.: "To: <user1@domain.tld>". This doesn't match then and so the proper sender identity gets not preselected when composing a reply even though there is a sender identity with the "user1@domain.tld" address available.

Interestingly when viewing the original message SOGo beautifies the "To" field into "To: me", so here apparently SOGo realizes the To address matches one of the available identities but just upon replying the correct sender identity is not preselected when the To field has only an email address but no name.

But for certain email addresses, e.g. group emails like <support@domain.tld> it is very common that people will put just the email address alone in the "To" field. So it would be awesome if you could still fix this too. Thanks!

Related Changesets

sogo: master 120f1280

2018-07-09 15:49


Details Diff
Use matching recipient address when replying

Fixes 0004495
Affected Issues
mod - NEWS Diff File
mod - SoObjects/Mailer/SOGoDraftObject.m Diff File
mod - UI/MailerUI/UIxMailEditor.m Diff File

sogo: master e5d3c5fa

2018-08-15 10:27


Details Diff
Lazier matching of recipient address

Fixes 0004495
Affected Issues
mod - UI/MailerUI/UIxMailEditor.m Diff File

Issue History

Date Modified Username Field Change
2018-06-28 18:05 isibaar New Issue
2018-07-09 19:55 francis Changeset attached => sogo master 120f1280
2018-07-09 19:55 francis Assigned To => francis
2018-07-09 19:55 francis Resolution open => fixed
2018-07-09 19:59 francis Status new => resolved
2018-07-09 19:59 francis Fixed in Version => 4.0.1
2018-07-18 17:43 isibaar Note Added: 0012965
2018-07-18 17:43 isibaar Status resolved => feedback
2018-07-18 17:43 isibaar Resolution fixed => reopened
2018-08-15 14:30 francis Changeset attached => sogo master e5d3c5fa
2018-08-15 14:30 francis Status feedback => resolved
2018-08-15 14:30 francis Fixed in Version 4.0.1 => 4.0.2
2018-08-15 14:30 francis Resolution reopened => fixed