Editing the "From" field for the current email only (as text, not dropdown)

The "Choose from a list of commonly used addresses" option is already available
-- just set up one account for each address you use. Point them all to the
right SMTP server. Point only one of them to the right POP/IMAP server. And
then when you're sending mail select the account you want the mail to come from
from the nice dropdown.

All of my mail comes to the same place - I get it all from one IMAP mailbox.
Only the outgoing address should change. Yes, I can create dummy outgoing
accounts, but this is a kludge. I still can't enter arbitrary outgoing
addresses. From should work just like To.

This enhancement would be very helpful for me, for spam fighting. Here's the
scenario: Whenever asked for an e-mail, I invent one on-the-fly (e.g.,
"<email address hidden>"). This is a valid e-mail because I've set
up <email address hidden> to reach me. Later I can easily discover who betray my
e-mail to spammers (and prove it), and I can easily filter by that address,
which is very useful in case it reaches many spammers.

With Netscape 4.x, I have to change my Preferences to do this. With Mozilla 6.x
this is even more cumbersome due to the more complex Account Settings dialog.
Since we're talking about a huge number of addresses generated on the fly,
opening a new account for each is not a viable solution.

I'm aware of several people using similar techniques.

Perhaps the easiest way to add this to the UI is to allow adding a "From" header
using the same widgetry that lets you add other headers ("Bcc", "Reply-to",
etc.). Such a "From" header, if present, overrides the e-mail specified in the
account. This is very consistent with the representation of these headers in
e-mail transport, and it hides the extra functionality in a very unobtrusive
manner. Should, however, do something sensible in case several "From" headers
are entered (error dialog?).

reassign to varada

*** Bug 98401 has been marked as a duplicate of this bug. ***

Isn't this bug asking for multiple identities? If this is the case then it is a
duplicate of bug# 48757.

No, it's asking (in essence) for per-message configurable identities.... so it
adds an additional feature request to bug# 48757. Maybe they should be merged?

Thinking outloud:

It seems like there are a bunch of concepts that 90% of people only need one of,
and the other 10% need lots of and lots of links between...

1. Incoming mail server
2. Outgoing mail server
3. Sending address
4. Recieving address
5. Folders

But it may be too complex to actually have each of these be treated as a
separate entity....

I just voted for this bug, and I'd like to explain why in text: First, I also
use the "anything@mydomain" philosophy to send E-mails. Second: I am a moderator
for some majordomo mailinglists, and as such have to add an "Approved" header to
the message when I do approve of its distribution. i.e.: I like the phrase "A
more general version of this would allow adding/changing arbitrary headers." in
the original report.

*** Bug 130371 has been marked as a duplicate of this bug. ***

*** Bug 131897 has been marked as a duplicate of this bug. ***

*** Bug 96180 has been marked as a duplicate of this bug. ***

From the bup bug:

Some users have their own (sub)domain name and generate email addresses on the
fly to track, what is being done with the addresses they give out to various
entities (like Amazon, Usenet etc.), esp. via webforms. When they communicate
with that entiry per email, they want to use that address as From in the email.

Other users have so many so rarely used addresses that they don't want to create
an account for each of them (I currently have about 20 accounts and still not
all my addresses covered).

It would be useful to specify a certain From address to be used not by the
read-only dropdown, but by a textfield which can be edited right in the
composer. The addressing pane normally used for recipients offers itself, for
code reuse reasons (e.g. can autocomplete to (my own) addresses in my address book).

I propose the following UI:
In the From dropdown, add a new special item "Custom" (or other wording). That
enables a "From" item in the header type dropdown in the addressing pane (under
"To", "cc", "bcc" etc.), which is otherwise invisible (not to confuse normal
users). It also creates a new row in that addressing pane, preselected to "From"
and maybe (!) the focus sat to it.

Security considerations:
I am aware that this makes forging emails much easier, esp. with autocomplete to
(all) existing addresbook entries.
It is not a new threat, however, because forging email addresses is already
trivial - you can create an account with an arbitary email address in Mozilla,
and pretty much all mails allow you to do similar.
Maybe this feature makes this existing threat even more widely known, which is a
good thing. Not many people are aware that emails can be forged that easily and
may trust the From line in incoming emails. I have even seen ISPs (jfax for
example) who use the From address for accounting (i.e. any fax sent as email to
a certain mail server with a customer email address as From is sent as fax and
billed to that customer). Such a feature may place an end to that insecurity.

Maybe mozilla should do what pine does. Don't allow custom From's unless it is
explicity turned on in the config. This will save clutter in the interface for
those who don't want it.

There should also be a build option to disable this for sysadmins that don't
want their users to do this (unless there is some way the sysadmin can set a
prefrence and not have the user override it. Is there?)

Adding CC.

jks comment 13

Why should there be a way for a sysadm to turn this off? they can't stop you
creating a new mail account can they which would accomplish the same thing (with
more work) If sysadms want to inforce this then they should IMHO harden the
rules on their SMTP relay.

Software in general comes with compile time options to turn things on and off.
While turning this off would provide no real security if users want to forge
From: headers, some sysadmins might balk at installing mozilla if they feel it
invites abuse. You wouldn't want lusers at some company forging mail to each
other, would you?

That is a B.S. assertion -- if you really want to forge, you can just change
your email address in the account setup, send a message, and change it back.

An average user might not think of that, since they would assume you need to log
in with a password to that account. I know turning off this feature would not
result in real security, but some sysadmins might want to install mozilla that way.

*** Bug 157781 has been marked as a duplicate of this bug. ***

*** Bug 158506 has been marked as a duplicate of this bug. ***

*** Bug 161084 has been marked as a duplicate of this bug. ***

*** Bug 17319 has been marked as a duplicate of this bug. ***

I would just like to ask, if this ever gets implimented, that it not only change
the from header, but also uses the from address with the smtp server for the
MAIL FROM command. This is because I don't want potention spammers to get my
real email address in a return-path header.

When are you ever worried about your Return-Path? When you send mail to
spammers directly?

A. There are mailing lists and such that will reject email where the envelope
doesn't match the "From:". Sometimes it's the mailing list spam filter ;-)
B. Some MTAs actually keep that information (qmail).
C. It's not even as if I can give fictitious email address for the envelope. If
I do, I won't be able to get rejects, which may actually be of interest to me.
D. Why not?

Yes, like Amazon.

I too want this feature. I've been cursing NS mail for years that I couldn't do
this! (I've changed my From address in preferences and keep forgetting to
change it back to my default.) Moz is better with multiple accounts, but not
quite what I need. I have used hundreds of unique addresses. I can't set up
fictitious accounts for all of them.

I just need to be able to edit the From address!

One way which I think would be very good from UI standpoint would be to make
this a folder option (which would override the account setting.) Since by far
the most common use for different addresses are to sort into folders, and even
if it isn't, one usually has folders for stuff that one needs separate addresses
for anyway.

Peter Anvin, this is offtopic. This bug is about the composer, there might be
other bugs for what you want.

It is not entirely offtopic. The composer takes its que from which folder you
are viewing. It defaults to the email address associated with the account the
the folder is under, so it wouldn't be a stretch to have a per-folder config
option to use a default email address when composing from that folder.

Exactly: the current default is based on the account associated with the folder
you are viewing. If there was a way to specify such a default per-folder
instead of per-account, it would go a long way toward resolving most (but
probably not all) such user needs.

taking all of varada's bugs.

I was taking a look at what was needed to get a quick hack working for this.

Is it possible to override the email address supplied in nsIMsgIdentity? or will
this cause problems with later saving those values back to prefs.js or indeed
with offline mail sending?

What I was thinking was adding a quick hack around line 1827 in
MsgComposeCommands.js and if there is a user edited header "From" then set this
as the value in the identity returned from getCurrentIdentity. Is that even
remotley possible?

http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgComposeCommands.js#1827

*** Bug 186014 has been marked as a duplicate of this bug. ***

The UI for custom headers is already in the Message Filters window, under
"Customize..." in the pulldown list of headers.

I suggest adding this UI also to the Compose window. It already uses pulldown
headers, but they are hardcoded to a predetermined set of 6: "To", "Cc", "Bcc",
"Reply-To", "Newsgroup", and "Followup-To". It seems straightforward to add
"Customize..." below this hardcoded list.

When this is done, and "From" is entered as a custom header, it would override
the noneditable "From" address displayed above the header list. The user could
enter a custom address, and the GUI could perhaps keep it in sync by changing
the displayed "From" address above to match this header. This would be a
special case, though, and I'm not sure if this is the right thing to do. Also,
multiple "From" headers are invalid, and would need to be blocked by the GUI.

Or perhaps it's easiest just to make the From field, as displayed above the
header list, editable? A checkbox, hidden away in Advanced preferences so
novice users won't check it by mistake, would be fine. If the From field can be
made editable in this way, it could then be blocked from inclusion in the custom
headers above, avoiding the complications described above.

So, the combination of these two features would work very well with each other:
* Advanced option to make the displayed "From" field editable.
* "Customize..." in the pulldown header list when composing a message, to allow
all custom headers to be added, except From (which is a special case).

I really hope this makes it into Mozilla, as it's the one reason I still go back
to Eudora sometimes when sending mail!

I'd like to at least be able to copy the header to a new message to report junk
mailers to abuse addresses.

Just added my vote to this bug; the inflexibility of from/reply-to configuration
is the only reason I do not use Mozilla for all my mail composition.

FWIW, my preference is for a configurable list of available addresses with a
per-folder default - a free text field in composition allows too much scope for
typos and random idiocy and allowing "From" as a customisable field overriding
the per-account combo is almost as nasty a kludge as creating multiple
pseudo-accounts.

In reply to Comment #36:
> a free text field in composition allows too much scope for
> typos and random idiocy and allowing "From" as a customisable
> field overriding the per-account combo is almost as nasty a
> kludge as creating multiple pseudo-accounts.

The "editable combo box" widget in Win32 and Java caters for exactly such
situations; I hope XUL has one.

Comment #3 gives a scenario where a fixed list is of little help.

I definately support having the ability to choose from multiple From addresses
that also show up as Reply-To Addresses.

I have found a way to do this in a user.js file which is a bit of a hack and I
would love native support.

Suggestion:

When making a new account you have choices like POP and IMAP. I ask for a third
choice there that is "Add an Identity Only (No Email Retreival)" that is exactly
like adding another POP account except there is no Incoming Server Settings at
all. You will be left with all the other settings for From address, Reply-to,
signiture file, et. al. These settings are associated accordingly when you
choose it in the "From" drop down dialog.

Currently my Mozilla works just like I have described except my additional
"From" addresses do not show up as actual identities because I went in and made
a user.js file and stored it in the folder that has prefs.js. user.js
overrides anything in prefs.js

I used an existing POP account as a template for making a new identity (funny
that Mozilla calls them identities in the prefs files) and I also saw that the
Local-Folder had it's very own NULL/non-exisiting server setting so I made the
copy of the first identity point to the Local Folder Server. I also had to add
it in the accounts list so that Mozilla would see it in the From field.

Skipping a little explaination I have found a way to make the From field give me
8 different email addresses and Mozilla only really has one real account setup
that it is checking.

In my job I have to respond to 8 different email addresses and needed a quick
way to choose them from a list. I give everyone here and especially the
engineers mondo kudos for a great product. I sincerely hope they will find a
way to allow us to add this kind of Identity Only (no email retreival) account
because it sure would be nice to be able to edit the signature file designation,
From name and address information all from the mail/newsgroups preferences
window instead of having to manually jiffy-rig this user.js file.

Comment #38:
"I ask for a third choice there that is "Add an Identity Only (No Email
Retreival)" that is exactly like adding another POP account except there is no
Incoming Server Settings at all."

To disable incoming server functions, uncheck them in Mail & News Acct Settings
| System Settings.

Adding a new feature to save the user unchecking those boxes seems like a poor
investment of our resources.

Anyway, this bug is about editable headers and not multiple mail identities.
Add a new bug, if there's not one already, if you don't agree with my assessment.

Re: Comment 39

"To disable incoming server functions, uncheck them in Mail & News Acct Settings
| System Settings."

Yes you may tell it to not check for new messages but Drawback #1 is it won't
allow you to put in bogus information very easily. For instance try putting in
the same server name and username for each bogus account. It won't let you do
that. You have to have different usernames. This is tricking the program
rather than having native support for alternate identities w/o associated
incoming server settings.

Also, I thought this avenue applied to customizing the headers in the From
field because you could add as many identities as you want through to wizard.
You don't have direct access to customizing the From field which should appease
those who do not want to be able to easily forge email addresses and spam
others while still allowing everyone complete customization over how they want
their email address to appear via a drop down menu. If you trick Mozilla into
having POP accounts with invalid and disabled incoming mailservers you are
still stuck with seperate mailboxes for each account. (Drawback #2)

My suggestion allows you to have 1 basic mail folder (Local Mail) and have many
different account identities that are not associated with incoming mail. (They
are associated with outgoing only) *and* most importantly it is configurable.
(If you don't want all those extra folders for each identity you don't have to
have them. If you want some extra folders all you have to do is add a folder
and setup your own filter.) Either way you wind up with a way to edit the
contents of the From field without having any of the other drawbacks.

However, comment #12 would be a fine way to handle it as well. Either way
would give you the opportunity to have more than one from address without
having to have some bogus incoming server settings. My way has an added bonus
of allowing you the ability to have custom signature files, From Names,
Organization (et al.) for each seperate identity you add.

In summary, Current version has a couple drawbacks in how it handles From
addresses.

#1, To get it to give you a custom From selection you have to have a valid
account associated with it, trick it to use an invalid account, or hack
together your own kludge of a user.js file.

#2, Currently people want a way to customize the From (and Reply-to) header but
they don't necessarily want seperate mailboxes for each from address. My
suggestion of adding a "Add an Identity Only (No Email Retreival)" option when
adding accounts would give you complete customization over how you want your
From field to display including other customization abilities while making it
hard for Joe Spammer to edit the From field right then and there to spam people
on a whim.

I may be a little offtrack from the original idea but I'm trying to find a way
to fold the original idea into something that will allow more control over how
you want your information displayed and this idea already works if you manually
put together your own user.js (prefs.js) file. Most of the work in designing
this feature is already done. They would just ne...

Created attachment 8553148
Possible patch

Comment on attachment 8551328
Backend changes

Review of attachment 8551328:
-----------------------------------------------------------------

::: mailnews/mime/src/mimedrft.cpp
@@ +1203,5 @@
> }
> }
> else
> {
> + from = MimeHeaders_get(mdd->headers, HEADER_FROM, false, false);

This hunk seems unnecessary?

(In reply to Joshua Cranmer from comment #118)
> > + from = MimeHeaders_get(mdd->headers, HEADER_FROM, false, false);
>
> This hunk seems unnecessary?

I accidentally already checked it in without review, so this is post-facto review, so to speak.

Comment on attachment 8551328
Backend changes

https://hg.mozilla.org/comm-central/rev/6fe2526c838f

Created attachment 8561373
Test fix

Comment on attachment 8561373
Test fix

Review of attachment 8561373:
-----------------------------------------------------------------

::: mailnews/compose/test/unit/test_messageHeaders.js
@@ +91,5 @@
> fields.organization = "World Salvation Committee";
> fields.subject = "This is an obscure reference";
> yield richCreateMessage(fields, [], identity);
> checkDraftHeaders({
> + // As of bug 87987 the identity does not override the from header.

Nit: comma after 'bug 87987'

@@ +96,1 @@
> "From": "Me <email address hidden>",

I assume you meant to also change the expected result here? Otherwise, this patch does nothing.

Created attachment 8562431
Fixed fix

Comment on attachment 8562431
Fixed fix

https://hg.mozilla.org/comm-central/rev/c3bf5c52ce41

Comment on attachment 8553148
Possible patch

Review of attachment 8553148:
-----------------------------------------------------------------

Sorry for the delayed review!

UI-Review:
------------
Minor Nits:
- "Customize From Address" is confusing. “Enter a custom address” perhaps?
- If you choose a custom address (which focuses the field), and then you deselect the field, and click it again, we should show the drop down (don't keep it editable).

Significant Problems:
- What if users try to use it as a separate address and they don’t actually have the account added to TB. Any replies to it will never show up.
  * (I'm thinking of naive users who think they can enter whatever address they "own" here without bothering to add the actual account, and expect us to add it automatically or something.
- What server are we actually sending this message through? We should probably have some capability to choose which one.
- Is this going to encourage spam sending? I can send a message as “<email address hidden>” now. I understand the capability was there already, but now it’s going to be even easier to do. This feature could be seriously abused.

Conclusion:
Is this feature too accessible? Should we hide this ability somehow? I can definitely see its value, but perhaps we need a pref for it.
I like the drop down UI though, just needs an option to pick the server.

Review:
------------

::: mail/components/compose/content/messengercompose.xul
@@ +171,5 @@
>
> <command id="cmd_convertCloud" oncommand="convertSelectedToCloudAttachment(event.target.cloudProvider); event.stopPropagation();"/>
> <command id="cmd_convertAttachment" oncommand="goDoCommand('cmd_convertAttachment')"/>
> <command id="cmd_cancelUpload" oncommand="goDoCommand('cmd_cancelUpload')"/>
> + <command id="cmd_customiseFromAddress" oncommand="MakeFromFieldEditable();"

*customize please. :)

@@ +172,5 @@
> <command id="cmd_convertCloud" oncommand="convertSelectedToCloudAttachment(event.target.cloudProvider); event.stopPropagation();"/>
> <command id="cmd_convertAttachment" oncommand="goDoCommand('cmd_convertAttachment')"/>
> <command id="cmd_cancelUpload" oncommand="goDoCommand('cmd_cancelUpload')"/>
> + <command id="cmd_customiseFromAddress" oncommand="MakeFromFieldEditable();"
> + label="&customiseFromAddress.label;"/>

Ditto.

::: mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd
@@ +302,5 @@
>
> <!-- Title for the address picker panel -->
> <!ENTITY addressesSidebarTitle.label "Contacts">
>
> +<!-- Identity popup customise menuitem -->

Ditto.

@@ +303,5 @@
> <!-- Title for the address picker panel -->
> <!ENTITY addressesSidebarTitle.label "Contacts">
>
> +<!-- Identity popup customise menuitem -->
> +<!ENTITY customiseFromAddress.label "Customize From Address">

Ditto.

::: mailnews/compose/src/nsMsgCompose.cpp
@@ +1066,5 @@
> + nsCString sender;
> + MakeMimeAddress(NS_ConvertUTF16toUTF8(fullName), email, sender);
> + m_compFields->SetFrom(sender.IsEmpty() ? email.get() : sender.get());
> + }
> +

All of this is unnecessary now because of your backend changes landing.

I don't think we need to worry much about abuse, it's really easy to do already if you're inclined to do so.
I do think servers these days are pickier than they used to so often it's not allowed to use an alias, or (e.g. gmail) they "fix" the sender if it's not one they accept. It would be good to communicate this somehow.

(In reply to Josiah Bruner from comment #125)
> - "Customize From Address" is confusing. “Enter a custom address” perhaps?
OK (but see below)

> - If you choose a custom address (which focuses the field), and then you
> deselect the field, and click it again, we should show the drop down (don't
> keep it editable).
You and your drop down again. What's going wrong on your system that you can't use an editable drop down? Making the field uneditable would unedit the custom address, so that's pointless.

> - What if users try to use it as a separate address and they don’t actually have the account added to TB. Any replies to it will never show up.
This is already possible via the multiple identity support.

> I like the drop down UI though, just needs an option to pick the server.
It uses the server of the address that you customised. (But then again you would know that if your editable drop down was working.)

> *customize please. :)
;-)

> All of this is unnecessary now because of your backend changes landing.
Well you didn't have review authority over it anyway.

Just to check your editable drop down, please can you try the following steps:
* Open an HTML Compose window
* Click in the message body area
* Format - Page Colours and Background
* Advanced Edit...
Under Attribute there should be a dropdown that gives you the options of background, bgcolor, text, link, vlink, alink, id, class, title, lang and dir but is also editable.

(In reply to <email address hidden> from comment #127)
> (In reply to Josiah Bruner from comment #125)
> > - "Customize From Address" is confusing. “Enter a custom address” perhaps?
> OK (but see below)
>
> > - If you choose a custom address (which focuses the field), and then you
> > deselect the field, and click it again, we should show the drop down (don't
> > keep it editable).
> You and your drop down again. What's going wrong on your system that you
> can't use an editable drop down? Making the field uneditable would unedit
> the custom address, so that's pointless.

After seeing what the editable dropdown *should* do, I agree.

>
> > - What if users try to use it as a separate address and they don’t actually have the account added to TB. Any replies to it will never show up.
> This is already possible via the multiple identity support.

Indeed, but I still worry that people will try using this for "quickly adding accounts", which of course won't work.

>
> > I like the drop down UI though, just needs an option to pick the server.
> It uses the server of the address that you customised. (But then again you
> would know that if your editable drop down was working.)

Hmm, guess I'll have to see the proper interaction then. Right now I'm still not convinced.

>
> > *customize please. :)
> ;-)
>
> > All of this is unnecessary now because of your backend changes landing.
> Well you didn't have review authority over it anyway.

Err, I wasn't suggesting I did (I didn't give it any review flag), I'm simply pointing out things you will want to fix before your next version. The backend changes in this patch causes it to not apply, that's all I was noting. :)

>
> Just to check your editable drop down, please can you try the following
> steps:
> * Open an HTML Compose window
> * Click in the message body area
> * Format - Page Colours and Background
> * Advanced Edit...
> Under Attribute there should be a dropdown that gives you the options of
> background, bgcolor, text, link, vlink, alink, id, class, title, lang and
> dir but is also editable.

Yes, that works fine, so I wonder what's going on in Compose. The dropdown in the compose window is styled pretty heavily after my compose changes in bug 867166 and children. Perhaps that's related? What platform have you tested this on? I'm surprised this issue wouldn't appear on all platforms, since the styling is fairly consistent.

(In reply to Magnus Melin from comment #126)
> I don't think we need to worry much about abuse, it's really easy to do
> already if you're inclined to do so.
> I do think servers these days are pickier than they used to so often it's
> not allowed to use an alias, or (e.g. gmail) they "fix" the sender if it's
> not one they accept. It would be good to communicate this somehow.

Yes, I agree we don't need to worry considerably, but it is worth pointing out. For example, simply having it there may confuse innocent, but naive, users who think they can use it to obtain whatever email they want. They may not realize the issues with this, and the problems it might cause later. I can see the bug already:

"Bug XXXXXX - I sent an email with a custom '<email address hidden>` address, ...

(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #125)
> UI-Review:
> - "Customize From Address" is confusing. “Enter a custom address” perhaps?

Agreed.

> - What if users try to use it as a separate address and they don’t actually
> have the account added to TB. Any replies to it will never show up.
> * (I'm thinking of naive users who think they can enter whatever address
> they "own" here without bothering to add the actual account, and expect us
> to add it automatically or something.
> - Is this going to encourage spam sending? I can send a message as
> “<email address hidden>” now. I understand the capability was there already,
> but now it’s going to be even easier to do. This feature could be seriously
> abused.

You question this whole feature, its very nature.

Spammers don't need Thunderbird, they have specialized tools. And spammers already do this in billions. This feature might actually help educating users how easy it is to forge email addresses, and to be more careful when they see From: <email address hidden> "Please update your address".

> - What server are we actually sending this message through? We should
> probably have some capability to choose which one.

* If you really want to pref this feature away, I think the best way would be a checkbox in "Account Settings..." | "Manage Identities...".
* If we insist that only one account can have this checkbox checked, it would solve the "which SMTP server" question
* But it would make this feature very obscure and hard to find.

> that's when we're all whacking our heads on our desks

This could be solved with a one-time (i.e.: "[ ] Show this again") message dialog explaining the feature with a simple 4-line text.

(In reply to Josiah Bruner from comment #128)
> The backend changes in this patch causes it to not apply, that's all I was
> noting. :)
Sure, but they'll get merged out when I update anyway.

> What platform have you tested this on?
Windows and Linux.

(In reply to Ben Bucksch from comment #129)
> * If you really want to pref this feature away, I think the best way would
> be a checkbox in "Account Settings..." | "Manage Identities...".
So, the presence of the "customize" option would depend on which identity you had selected?

(In reply to Ben Bucksch (:BenB) from comment #129)
> (In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #125)
> > UI-Review:
> > - "Customize From Address" is confusing. “Enter a custom address” perhaps?
>
"Customize From Address"|"Edit Sender" vs. "Enter a custom address" are two different design concepts.

"Customize/edit..." assumes we're using existing identities (including their predefined smtp), and only allow changing the sender string. This design does not work well as a dropdown entry at the end of the list, but requires UI elements/procedures to start from the currently selected sender identity.

"Enter a custom address" (as last entry from dropdown list) suggests we allow adding a *new* sender, which would most certainly require to allow picking SMTP, too (because otherwise from this design it would not be clear which SMTP will be used).

Both concepts have their advantages and disadvantages, which we are in the process of discussing.

>
> > - What if users try to use it as a separate address and they don’t actually
> > have the account added to TB. Any replies to it will never show up.
> > * (I'm thinking of naive users who think they can enter whatever address
> > they "own" here without bothering to add the actual account, and expect us
> > to add it automatically or something.
> > - Is this going to encourage spam sending? I can send a message as
> > “<email address hidden>” now. I understand the capability was there already,
> > but now it’s going to be even easier to do. This feature could be seriously
> > abused.
>
> You question this whole feature, its very nature.

Fortunately, it's allowed to question the nature of a feature.
This feature is very questionable, and comes with a high potential for user errors.

> Spammers don't need Thunderbird, they have specialized tools. And spammers
> already do this in billions.

+1

> This feature might actually help educating
> users how easy it is to forge email addresses, and to be more careful when
> they see From: <email address hidden> "Please update your address".

Well, maybe. I believe its more likely we'll end up with users who accidentally break their communications (failing deliveries; not getting replies).

> > - What server are we actually sending this message through? We should
> > probably have some capability to choose which one.
>
> * If you really want to pref this feature away, I think the best way would
> be a checkbox in "Account Settings..." | "Manage Identities...".
> * If we insist that only one account can have this checkbox checked, it
> would solve the "which SMTP server" question
> * But it would make this feature very obscure and hard to find.

+1. Limiting this feature to one account is not required and very poor design.

For ux-error-prevention, I suggest that this feature should not be actively promoted in the primary UI.
There might be several ways of achieving this, e.g.
- pref-out for each identity
- allow editing only after double-click on sender (plus first-time warning)

Created attachment 8572084
Possible patch

I hid the option in the Options menu where it might be less discoverable.

(In reply to Thomas D. from comment #132)
> - allow editing only after double-click on sender (plus first-time warning)
Probably not possible because the popup code gets in the way.
Also, what do you do from the keyboard?

(In reply to <email address hidden> from comment #133)
> Created attachment 8572084
> Possible patch
>
> I hid the option in the Options menu where it might be less discoverable.

Screenshot would be nice.

> (In reply to Thomas D. from comment #132)
> > - allow editing only after double-click on sender (plus first-time warning)
> Probably not possible because the popup code gets in the way.
> Also, what do you do from the keyboard?

Got me. Double-click isn't keyboard accessible... :|

Given the questioning about the nature of this, why is this being promoted as a core feature instead of as an addon? It seems to me this is exactly why we have addons.

There is a fine addon out there called Virtual Identity which works well (most of the time).

I see no addon by the name of Virtual Identity...

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

I'm wary of anything that can't be found through Mozilla's directory...

> Given the questioning about the nature of this, why is this being promoted as a
> core feature instead of as an addon? It seems to me this is exactly why we have addons.

Please. You have to stop questioning features *after* they are implemented. This bug is almost 14 years (!) old, and Mozilla always had addons, that's plenty of time to raise objections like that, not when there's a patch ready to land.

I an using the "Virtual Identity" addon since many years, but that very fact that I need certain addons (I can't use Thunderbird without them), and that they are not always up-to-date, prevents me from using Thunderbird trunk. I'd like to use a stock Thunderbird trunk build, at least for my most important needs, without depending on addons for everyday work. I currently have to use an age-old Thunderbird (which is insecure), because of the addons. Addons are good for integration with your telephony provider, but not for basic emailing needs.

FWIW, this is why I financed this patch and paid Neil to implement it, in core TB.

(In reply to Ben Bucksch from comment #129)
> > * If you really want to pref this feature away, I think the best way would
> > be a checkbox in "Account Settings..." | "Manage Identities...".

> So, the presence of the "customize" option would depend on which identity you had selected?

No, I'd make it so that only one identity can have this checkbox checked (in Account Settings), and that one identity would always be used for custom email addresses.

That said, I do *not* think that we should pref this away. I think Neil's patch was just fine.
But I can see the argument.

Personally, I'd just add a one-time message that explains the feature and warns people.
"Nnormally, you should add your email addresses in Account Setup.
This feature here is for users who want to use a custom author email address depending on their recipient, for example <email address hidden> or <email address hidden>.
It is only for your own email addresses. Impersonating other people may be subject to punishment by law."

Comment on attachment 8572084
Possible patch

Review of attachment 8572084:
-----------------------------------------------------------------

Options menu is the wrong place for this. If a checkbox, it should be in Account Settings.

Created attachment 8574154
Screenshot showing the moved menuitem

Created attachment 8581305
Screenshot of normal dropdown (Linux)

This shows the dropdown when it's not yet editable. I can select identities like before.

Created attachment 8581307
Screenshot of editable field (Linux)

After clicking on the last entry of the dropdown, labeled "Customize From Address", the field is editable (it's now a combobox).

When changing the value, it continues to use the identity that was selected before, but uses the entered From address. I verified with 2 different accounts that this is really the case: Different SMTP servers were used, depending on which identity was selected first.

Please note that there's a minor UI glitch here: We have 2 dropdown arrows, as you can see in the screenshot. They both have the same effect. When clicking the right one, the left one even shows a pressed state.

When I select an identity, click "Customize From Address", and edit it, I then can still select other identities, and they will apply. That's good.
But when I select the same identity that I originally selected, I do not return to the original From address, but my edited one stays. That's odd. I'd argue that all dropdown entries should behave the same and reset the edit field's value. However, that's a minor thing and also debatable. I wouldn't hold the commit for that.

Last but not least, we should probably add a one-time warning dialog, like proposed in comment 142.

Aside from this (and reviews of course), this works very well, it's good UI, and I think it's ready to land. The UI interaction is fairly natural and very intuitive.

(In reply to Ben Bucksch (:BenB) from comment #147)
> When I select an identity, click "Customize From Address", and edit it, I
> then can still select other identities, and they will apply. That's good.
> But when I select the same identity that I originally selected, I do not
> return to the original From address, but my edited one stays. That's odd.
> I'd argue that all dropdown entries should behave the same and reset the
> edit field's value. However, that's a minor thing and also debatable. I
> wouldn't hold the commit for that.

Not being able to reset an edited sender to its original state does not look like a minor issue to me.
How does this affect recycled compose windows?

UX input: I definitely want this feature pref'ed off. This is very advanced stuff, and quite hazardous when used wrongly (users might not notice, or too late, that their important emails haven't been sent by server because they mis-tweaked their sender address). Just warning once imo is not enough.

I'm not happy with the warning text in comment 142.
E.g. the danger of failing to deliver is not even mentioned. Warning users against committing crimes is inappropriate for TB imo. It's probably not easy to get the warning right. The warning is less relevant when the feature is pref-ed off, so only people who really want this and know what they are doing will switch it on.

On the plus side, the gmail scenario is quite powerful, being able to create <email address hidden> on the fly might be useful. Otoh, I'm not sure how many usecases/scenarios there would be where I'd want to use such an email address only exactly once. For repetitive use (even 2 times), it's probably more useful to set up another identity on an existing account.

I still think that the current UI for this is wrong because it's disjunct/dislocated.
If we allow to edit the currently selected sender, then the control to start that should be near that sender. Clicking at the low end of a dropdown to edit the current entry at the top is bad UX imo.
Also, there's a scalability problem for users having many pre-defined accounts and identities. That command to edit the sender might end up as the 50th entry, requiring scrolling to see it and other such nuisance.
Just never put action commands to the end of a potentially unlimited list of things. We've tried that before (TB Tags list), and it never works. That's basic UX principles, really.

(In reply to Thomas D. from comment #151)
> Clicking at the low end of a dropdown to
> edit the current entry at the top is bad UX imo.

So, top of the dropdown then? Or do you prefer attachment 8574154?

(In reply to Ben Bucksch from comment #147)
> when I select the same identity that I originally selected, I do not
> return to the original From address, but my edited one stays.

Huh, I wonder why that happens.

> So, top of the dropdown then?

No, the bottom is fine. We don't want this to be prominent.
Furthermore, the end makes sense, because this should only be used when none of the other From addresses are OK. It's kind of a "more" option.

*All* the options in the dropdown change the textfield value. The "custom" is the least that you should use, so it belongs at the bottom.

(In reply to Ben Bucksch from comment #146)
> Please note that there's a minor UI glitch here: We have 2 dropdown arrows,
> as you can see in the screenshot. They both have the same effect. When
> clicking the right one, the left one even shows a pressed state.

OK, so this is to do with the changes in bug 906264; they don't play nicely with editable menulists on Linux (the editable menulist looks fine with them removed; there's also a good chance that they're causing problems on Mac too.) I don't know whether I should remove them or just file a bug to get them updated to work with editable menulists.

Created attachment 8583150
Revised patch

Now resets the From address correctly when you select the current identity from the drop-down, adds a one-time warning dialog, and removes the Linux/OSX CSS because that wasn't working in its current state.