1254666 - "edit as new message" on a received message prefills the sender as the composing identity

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[:aceman]

If you use "Edit as new message" on a received message, the sender of that message is used as the From identity for the new composed message.
The To field is filled with "me" (the recipient of the original message).

So in a way it is working correctly, it makes a correct copy of the original message. However sending such a message does not make much sense, so we could be more helpful.

This is at least a change in behaviour after TB38. In there MY identity from the used account is used for the new composition as the From address.

Could be caused by bug 87987 or similar in that area.

Comment 1

[Jorg K (CEST = GMT+2)]

My 3 cents worth of wisdom:
I usually edit my own messages as new, not some other people's ;-)

On TB 38 editing a message as new that was sent to me gives me From and To the same (oh, you said this).

I don't have a strong opinion either way, but I think we should revert to the original behaviour.

Comment 2

[Magnus Melin [:mkmelin]]

Well, it kind of solves bug 279846 which is a bit of a problem when you're using multiple desktops, only that the SMTP may not let you send with the address you set, and copies go to wrong folders etc.

Comment 3

[:aceman]

Is bug 903390 you just fixed related to this?

Comment 4

[Magnus Melin [:mkmelin]]

I don't think it's very related. That only changed some things for reply-to-self.

Comment 5

[Vid Kovacic]

I can confirm the bug on the Windows platform in Thunderbird 45 as well.

Comment 6

[:aceman]

(In reply to Jorg K (GMT+2) from comment #1)
> My 3 cents worth of wisdom:
> I usually edit my own messages as new, not some other people's ;-)

Yeah, I also need to remember why I am doing something like that :) As if I want to swap the To and From, I should use Reply :) So maybe we could disable Edit as new on received messages.

Comment 7

[:aceman]

(In reply to Vid Kovacic from comment #5)
> I can confirm the bug on the Windows platform in Thunderbird 45 as well.

Hi, thanks for confirmation. However, can you tell us what the use case is here? Why is 'edit as new" needed on received messages instead of Reply or Forward?

Comment 8

[Vid Kovacic]

Well, it's easier to use "Edit as new" if you want to make an email appear as you wrote it. 

"Forward" adds a "Fwd:" into the Subject line and a table with original subject, date, from and to info into the message body.

More importantly: if you are using "Edit as new" on a message you have received it should automatically put you as the sender and not the original sender. Cause it will be you who is sending it out.

Comment 9

[:aceman]

Yes, thanks.
Copying some text and sending to somebody else but not showing it is actually forwarded (or received from somebody first). Sounds reasonable.

Comment 10

[Wayne Mery (:wsmwk)]

This works on 12-13 nightly, fails on 12-20 nightly. So I'm fairly confident bug 87987's first checkin on 12-13 is related.

Think you can fix it up?

Comment 13

[:aceman]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #10)
> Think you can fix it up?

Yeah, now that Neil is MIA and this is accumulating dupes, which means I did remember correctly and this behaviour did change, I could try to look at it.

Comment 16

[Mark Smith [:mcs]]

Bug 1269849 (which I opened) was marked as a duplicate of this one, but the discussion here does not capture my main complaint in bug 1269849: Edit As New Message forces the From field to enter customized/editable mode. Is there a way to leave customized/editable mode?

Comment 17

[Jorg K (CEST = GMT+2)]

If you feel that there is a feature missing since you can't get out of that mode, please raise another bug.

I thought selecting another pre-canned identity gets you out, but it doesn't. Perhaps it should.

Comment 18

[Jim Porter (:squib)]

I don't know if this bug is valid; if someone told me they were editing a message "as new", I'd expect the From address to remain the same, even if it wasn't one of my identities. Comment 16 is a valid issue, though.

Comment 19

[Jim Porter (:squib)]

Er, I should add: maybe we could add an alert in this bug to inform the user that they're using a custom value for From? Then it's up to the user whether to keep that or use one of their identities.

Comment 20

[:aceman]

(In reply to Jim Porter (:squib) from comment #18)
> I don't know if this bug is valid; if someone told me they were editing a
> message "as new", I'd expect the From address to remain the same, even if it
> wasn't one of my identities.

Yes, but not only it isn't one of your identities, most of the time using it would not work as any server should reject it, as it is not you identity (email). What would be the purpose to create invalid/fake messages locally? Do you see a use case?

Comment 21

[Jim Porter (:squib)]

We can't tell if it's an old "identity" that you've deleted, or if it's an identity with the "+foo" syntax, like "[e-mail]". You may also be forwarding a message on behalf of someone else. Even Gmail should let you put any address in the From field (although they also add a Sender field with your account's address).

However, it's especially odd to me that if I manually hit "Customize From Address", it warns me, but if I edit as new, it doesn't.

Comment 22

[Wayne Mery (:wsmwk)]

I got burnt by this once.  At a bare minimum, it shouldn't allow sending from an unknown idenity unless some bar is satisfied - like I've clicked on a button, or checkbox, or editted the field.  Passive alert like color doesn't cut it.

Comment 23

[Magnus Melin [:mkmelin]]

(In reply to Jim Porter (:squib) from comment #21)
> forwarding a message on behalf of someone else. Even Gmail should let you
> put any address in the From field (although they also add a Sender field
> with your account's address).

They only allow you to set the From field to one your registered aliases, or a plus address. If the address you provide is not one of those it silently swaps it to your official address.

Comment 24

[Jim Porter (:squib)]

Ah, true. I'd still classify that as "any address", though. You just need to do a bit of extra setup.

I still think we're doing the right thing here, *except* that we're not doing a good job of informing the user. We could show a popup like we do when you manually choose "Custom From Address", or throw up an alert before sending, or maybe add a notification like we do for missing attachments.

Comment 25

[:aceman]

Can we show a question if TB should use the currect From and To addresses or swap them?

Comment 26

[Charles]

My .02c...

I have been using 'Edit as new' extensively for a very long time, and the only thing that makse sense to me is for the From to be set to my Identity - which is, incidentally, how TB 45 is working for me right now.

I honestly don't remember what it used to put for To:, but it is currently setting that to my identity as well.

Personally, I'd prefer the To: was left blank, but I would definitely not want the From: to be the original sender, that makes no sense to me.

I use this to create a new email from something else (sometimes something I sent, sometimes something someone sent me), but I usually edit it (often heavily), and either send it to someone right away, or save it as a template, or something else.

Comment 27

[Lucien Gentis]

Hi,

I personally think that default sender address when I use "Edit as new message" should be my address, not that of original message.

It could "encourage" the user to send messages in the name of another person.

Comment 30

[dr.kral]

Edit as new used to work until recently.  Coincidentally with the addition os the customizable sender or about then.  Now regardless of the original sender or if the new sender is changed the msg is rejected with the mess is in a popup box -- << Sending of the message failed. An error occurred while sending mail: the return mail address was invalid. Please verify that your email address is correct in your account settings and try again. >>

Comment 32

[Yann 'Ze' Richard]

This is a regression : the effect of the 'Edit as new' have changed and not documented.

"Edit as new" is understood as being "take this content and permit me to make a new mail with it" by users.

The real effect of is change is : users sent email with an identity that is not theirs (because they do it before and not warned about Sender change) ! Users thinks that thunderbird never sent email with unknown identity.

Is it possible first revert to avoid this regression and after perhaps reopen a bug/feature request to complete with user alerts etc.. if any want to "edit as new" with a "fake" identity ?

Comment 34

[:aceman]

Just noting that Outlook (2010) does the same as the current TB behaviour. Clicking "Send this message again" opens the editor with the message pre-filled and the original sender is also the sender now. And I am the recipient.

BUT, Outlook does warn the user that this will happen (that you are not the original sender), but there is no option to avoid it. Just fix the addresses in the presented composition.

I think this says something, that users liked the previous TB behaviour (are not just conditioned from other clients) as it was useful.

So can we get a decision here? I'm willing to try to implement it, even a dialog where user can choose whether to swap the recipients or not.

I'm not sure if this also affects Seamonkey (if it got all the features of bug 87987).

Comment 35

[Charles]

(In reply to :aceman from comment #34)
> I think this says something, that users liked the previous TB behaviour (are
> not just conditioned from other clients) as it was useful.

Not sure what you mean... based on context, it sounds like you mean the original sender used to be set as the new sender in the new email?

If that is what you mean, that is not correct, it has always set the new sender to be mine...

I know this for a fact, I used this feature all the time, and would have complained about it if it used to do otherwise.

Comment 36

[Charles]

So, basically, I'm saying that it is still - now, in 45 - working as it always has for me... setting me (current identity) as the new sender.

As I said previously, I don't remember if it also set my identity as the To:, but that is what it is doing now - I would in fact prefer that to be blank, but it isn't a big deal, as sometimes I do send these to myself.

Anyway, as I said earlier, setting the From to any identity other than your own makes absolutely no sense to me, as it will in almost all cases fail to send or reach its destination).

Comment 37

[:aceman]

(In reply to Charles from comment #35)
> Not sure what you mean... based on context, it sounds like you mean the
> original sender used to be set as the new sender in the new email?
> 
> If that is what you mean, that is not correct, it has always set the new
> sender to be mine...

No. I say "original sender IS set as the new sender in the new email" NOW. The previous behaviour was that sender and recipient (me) was swapped so I am now the sender of the composed message. This bug is about restoring to this original behaviour.

(In reply to Charles from comment #36)
> So, basically, I'm saying that it is still - now, in 45 - working as it
> always has for me... setting me (current identity) as the new sender.

That is kinda strange as this bug and the ~10 dupes say that this is no longer happening. You are NOT set as the new sender (the original sender of the reused message is set as sender of the new one).

> Anyway, as I said earlier, setting the From to any identity other than your
> own makes absolutely no sense to me, as it will in almost all cases fail to
> send or reach its destination).

Yes, that is what this bug says. But you could see voices in this bug that this (setting someone else as From) could actually be logical, as it now creates an identical copy of the message.

Comment 38

[Numalliance IT]

The problem is that my users do not understand this change.
For a simple user send an email instead of another user (whatever the address) is not normal or even dangerous for company.

If this is not a bug, the menu should be changed
 - Change 'Edit As New Message' by 'Send this message again as ...' (like Outlook)
 - Popup warning before send

Comment 39

[Charles]

(In reply to :aceman from comment #37)
> (In reply to Charles from comment #36)
>> So, basically, I'm saying that it is still - now, in 45 - working as it
>> always has for me... setting me (current identity) as the new sender.

> That is kinda strange as this bug and the ~10 dupes say that this is no
> longer happening. You are NOT set as the new sender (the original sender of
> the reused message is set as sender of the new one).

Very strange...

>> Anyway, as I said earlier, setting the From to any identity other than your
>> own makes absolutely no sense to me, as it will in almost all cases fail to
>> send or reach its destination).

> Yes, that is what this bug says. But you could see voices in this bug that
> this (setting someone else as From) could actually be logical, as it now
> creates an identical copy of the message.

Respectfully disagree. The menu choice is 'Edit as New', not 'Edit as New Identical Copy'.

I would also argue that the use case for wanting to send as the original sender is far, far lower than the one where you want to send it as yourself (or one of your own identities) but just save yourself the work of retyping or even copy/pasting (and fixing formatting issues).

So, if someone wants this new behavior, in my opinion it should be implemented as a new feature (add menu choice for 'Create identical copy as New', not replace the much more logical old (current for me) behavior.

Now the question is why, for criminy's sake, is it still working the old way for me (meaning, why am I not experiencing the bug? Wonder what I can do to try to see why?

Comment 40

[Magnus Melin [:mkmelin]]

I think we should fix this by doing what we did before (use default). 
It would be good to if possible handle bug 279846 at the same time, since that is now semi fixed (uses correct address, but not necessarily from the right account, if the alias is set up on multiple accounts).

Comment 41

[Jorg K (CEST = GMT+2)]

+1.

Comment 42

[info]

I wouldn't want anyone to send an e-mail with my identity without me knowing. However it is possible with SMTP but the new "as new" behaviour seems to be a too comfortable tool to do this. And I can't think of a single reasonable, legal use case.

Comment 43

[Tom Harding]

This issue has rattled our organization (1000 clients) when a message with an obviously wrong sender reached a large group of people.  It was not the person's intention to impersonate.  This new undocumented change caused the problem.

I agree with comment 32, this is a regression and should be reverted to the original behavior of using the re-sender's identity as From.

Comment 44

[Toadstool]

I agree with comments 32 & 43; this is a regression.

With multiple daily status calls we use "Edit as new message" to avoid generating huge email chains while allowing each status call facilitator to retain the last status format.  I just accidentally "spoofed" somebody else's email address when I sent the latest status email to 400+ staff in our organization.

This is a security concern and should revert to the actual sender of the email.

Comment 45

[Numalliance IT]

+1
it's the same problem in my organization

(In reply to Toadstool from comment #44)
> I agree with comments 32 & 43; this is a regression.
> 
> With multiple daily status calls we use "Edit as new message" to avoid
> generating huge email chains while allowing each status call facilitator to
> retain the last status format.  I just accidentally "spoofed" somebody
> else's email address when I sent the latest status email to 400+ staff in
> our organization.
> 
> This is a security concern and should revert to the actual sender of the
> email.

Comment 48

[Charles]

Is it possible this bug is on Linux only?

Because I am not experiencing it.

I'm currently running two Windows versions - 45.1.1 installed, and 45.1 Portable, both on Windows 7 Pro 64bit, and both are working as they always have - clicking 'Edit as new' sets both Sender and Recipient to me.

Comment 49

[Jorg K (CEST = GMT+2)]

(In reply to Charles from comment #48)
> Is it possible this bug is on Linux only?
No, clearly happens on Windows, too. <ctrl>E on a bugmail and you get:
From: Bugzilla@Mozilla <[e-mail]>

Comment 50

[Charles]

Ok, I didn't really see how an Addon could 'fix' it for me, but tested in Safe Mode - and now I do experience the bug.

Now to figure out which one is fixing it for me...

Well, that was easy...

It is the 'Virtual Identity' Addon:

https://www.absorb.it/virtual-id

Comment 55

[Jorg K (CEST = GMT+2)]

So the behaviour we need to re-establish is this:

If the message uses one of the identities as sender, us it.
Otherwise: If the message is stored in a folder belonging to account X, use account X's default identity.
Otherwise: If the message is stored in a local folder, use the default identity of the first account.

Sounds right? I played around with TB 31 and this is what is seems to do.

This should be easy since bug 87987 only landed this:
https://hg.mozilla.org/comm-central/diff/0f98648f72ae/mail/components/compose/content/MsgComposeCommands.js

I'm onto it ;-)

Comment 56

[Jorg K (CEST = GMT+2)]

Attachment: Possible fix (v1).

This half-line change should fix it.

mozmake SOLO_TEST=composition/test-newmsg-compose-identity.js mozmill-one
still passes, so "edit as new" was obviously not tested.

Comment 57

[Charles]

(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #55)
> So the behaviour we need to re-establish is this:
> 
> If the message uses one of the identities as sender, us it.
> Otherwise: If the message is stored in a folder belonging to account X, use
> account X's default identity.
> Otherwise: If the message is stored in a local folder, use the default
> identity of the first account.
> 
> Sounds right?

Sounds perfect Jorg - thanks for taking it on!

Comment 58

[Jorg K (CEST = GMT+2)]

(In reply to Charles from comment #57)
> Sounds perfect Jorg - thanks for taking it on!
My patch just restores the original behaviour of "edit as new", nothing more and nothing less. That seems to be what I described in comment #55.

Comment 59

[Charles]

Yep, and I still say 'perfect'! :)

Hopefully there will be no problem fixing this in 45?

Comment 60

[Jorg K (CEST = GMT+2)]

(In reply to Charles from comment #59)
> Hopefully there will be no problem fixing this in 45?
Let's get it reviewed and landed first, then we talk about uplifts ;-)

Comment 61

[:aceman]

Comment on attachment 8769894 [details] [diff] [review]
Possible fix (v1).

Review of attachment 8769894 [details] [diff] [review]:
-----------------------------------------------------------------

So, this basically reverts the behaviour to before bug 87987. I.e. if you send a message with an edited custom identity (feature of bug 87987) and then try to 'edit as new' (you own msg, which makes even more sense), the custom identity is NOT preserved after this patch and one of the defined identities is used. That is kinda to be expected as TB can't determine if that unknown custom identity is your's or somebody else's. So we have to live with this if we do not want to copy somebody else's identities.

You make an exception for drafts, where when editing a draft we keep the From identity whatever it is in the draft (even custom one) as there we can expect the sender is always us.

How hard would it be to also do this exception when doing 'edit as new' on a draft (also preserve whatever From is there)?

Comment 62

[Jorg K (CEST = GMT+2)]

(In reply to :aceman from comment #61)
> So, this basically reverts the behaviour to before bug 87987.
Yes.

> You make an exception for drafts, ...
Yes, since they are likely to edit the From, save the draft and then return to it later.

> How hard would it be to also do this exception when doing 'edit as new' on a
> draft (also preserve whatever From is there)?
I don't know off hand, I'd have to look into it. Or maybe you can ;-) (I'm happy to pass the bug along, I just started because I saw no action and got tired of the bugmail with more and more complaints.)

Conceptually I find a little questionable to make "edit as new" act differently when operating on a draft or even template. I'm not sure whether at that point you can tell the folder where the message came from.

Sadly the computer has no AI to detect a message you deliberately manipulated ("you own msg", as you call it) for a foreign one. All you could do is base it on the folder.

Comment 63

[:aceman]

(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #62)
> Conceptually I find a little questionable to make "edit as new" act
> differently when operating on a draft or even template. I'm not sure whether
> at that point you can tell the folder where the message came from.

I do not mean folder it came from. But we have this "edit as new" on draft msg, that opens a new copy of the draft without editing the old one. But at that point it may be hard in ComposeStartup to know we actually came from a draft (as we intentionally split the link to the original draft to force the composer to make a new copy).

> Sadly the computer has no AI to detect a message you deliberately
> manipulated ("you own msg", as you call it) for a foreign one. All you could
> do is base it on the folder.
Yes, that is why I am OK with scraping this and only use the new logic (preserve From) on drafts.

Comment 64

[Jorg K (CEST = GMT+2)]

Thanks. This can be landed with other stuff, let's save some server resources.

Comment 65

[Jorg K (CEST = GMT+2)]

Comment on attachment 8769894 [details] [diff] [review]
Possible fix (v1).

[Approval Request Comment]
Regression caused by (bug #): Bug 87987.
User impact if declined: A bunch of really unhappy users.
Testing completed (on c-c, etc.): Manual testing.
"edit as new" with modified From address doesn't appear to be part of the test suite.
Risk to taking this patch (and alternatives if risky):
Close to zero. Restores previous behaviour for "edit as new".

Note: TB 48 beta is being built at time of writing, so too late for that version.

Comment 66

[Jorg K (CEST = GMT+2)]

For the purists: TB 50 will be fixed after landing the patch ;-)

Comment 67

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/comm-central/rev/93150e9ac154

Comment 68

[Jorg K (CEST = GMT+2)]

Attachment: Better fix (v1).

I've been working on bug 1169184 and I've been thinking when to restore the saved content language.

It occurred to me that the presence of draft info tells us whether this is a draft or template we prepared. When editing it or editing it "as new" we can preserve what we prepared previously.

Aceman, what do you think? Is this the solution you were looking for?

Comment 69

[:aceman]

How exactly does composeFields.deliveryFormat relate to "draft info" ?

Comment 70

[Jorg K (CEST = GMT+2)]

X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=1; DSN=1; uuencode=0;
 attachmentreminder=0; deliveryformat=4

;-)

Comment 71

[:aceman]

The patch does not work for me. Any message (even received) does have deliveryformat defined at that spot you check it. It probably has a default.

Comment 72

[Jorg K (CEST = GMT+2)]

Comment on attachment 8770983 [details] [diff] [review]
Better fix (v1).

It doesn't work for me either. Sorry. Basically, checking for the "draft info" is not a bad idea, since drafts and templates carry it.

if ((gComposeType == nsIMsgCompType.Draft || gComposeType == nsIMsgCompType.Template) && params.composeFields.from) ...

doesn't work since all messages edited "as new" have nsIMsgCompType.Template.

I'll let you know if I can come up with something better or we just go with what we we have.

Related issue: Over in bug 1169184 I'd really like to restore the language for (own) drafts and templates but not for "foreign" messages, since as Magnus mentioned many times, the Content-Language header doesn't have the correct information.

Comment 73

[Jorg K (CEST = GMT+2)]

Sorry, I don't have a better solution right now. I'll pursue the matter further in bug 1287268. This will need a change to nsIMsgCompFields.idl, so it can't be uplifted to TB 45.x.

In TB 45.x we'll have to live with the solution landed here, that is, "edit as new" of whatever message does not keep the edited From.

Comment 74

[Jorg K (CEST = GMT+2)]

Aurora (TB 49):
https://hg.mozilla.org/releases/comm-aurora/rev/5a9f587d9da8

Comment 75

[Charles]

News on uplifting to 45?

Comment 76

[Jorg K (CEST = GMT+2)]

You'd have to ask Kent. The situation is this: Kent dislikes uplifting to TB 45.x if there has been no exposure to it in a beta. This is in TB 49 beta, but the build has failed so far. Kent mentioned doing a 45.3 soon, but following this rule, this patch won't be included.

However, if you put a good case forward, Kent might include it, since it's a trivial change that IMHO will not cause any problems or regressions.

Kent, can nine votes convince you?

Comment 77

[Charles]

Make it 10 votes (just noticed I hadn't voted yet).

Also, Kent, this is not only a trivial patch, it is restoring previous behavior.

Pretty please?!?! :)

Comment 78

[Kent James (:rkent)]

I agree it is a trivial patch. Any hope of getting a beta done with this? (Or any beta for that matter)? This is a reasonable candidate for ers45.

Comment 79

[Jorg K (CEST = GMT+2)]

As I said in comment #76: This *is* in TB 49 beta, only that we can't build it right now.

Comment 80

[Kent James (:rkent)]

By popular demand, esr45+

Comment 81

[Kent James (:rkent)]

https://hg.mozilla.org/releases/comm-esr45/rev/51893f9780c5aa8a152ca1bfecaa46d31bf317e1