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...

> I may be a little offtrack from the original idea

Unfortunately, you are totally offtrack. You are talking about bug 44863. FYI, I
am not sure that this implementation proposal is a particularily good idea, see
the other bug for more info.

It seems that other bug is focused on signatures primarily. I'm trying to point
out a way that could allow one control over how they handle their mail and
customize it to suit their needs.

As per the original request for this thread:
"Often, I want to send a message that appears to come from someone else. For
example, I respond to e-mails directed to <email address hidden>, and I want
my messages to appear to come from that address."

By having multiple non-receiving identities you are allowed to have multiple
'From field' choices that don't necessarily need to check mail or trick the mail
prog with false information. This request and the one pointed out in the last
reply for customizable sig lines could be taken care of all together.

Currently I receive 8 email accounts all on my primary email address. I send
replies to customers from each address and have the choices in the dropdown
menu. Each one also has it's own sig-file assoicated with it, which for this
discussion isn't a big deal, but it's a nice option to have. The only problem
with this is that in order to maintain the account settings I have to edit a
manually created user.js file that I made. I only have 1 actual account and 1
set of folders for that account. If I needed extra folders those can already be
created.

All that it took to accomplish the goal of wanting to send mail that appears to
come from someone else was already built in to the prefs.js file for mail
settings. It just took a hybrid account type that was an amalgam of a real POP
account but used the bogus server settings of a Local Mail folder and was
disabled from being checked when getting new mail. This hybrid amalgam could be
created inside the program very easily as an alternate account type instead of
requiring the user to kludge together his own solution and would be very
customizable.

If you don't believe this to have any bearing on adding or changing headers
arbitrarily then I must appologize for not making myself clear enough. Those
headers would be customizable within the account manager interface and allow you
to have as many extra From addresses as you need to take care of the different
hats you must wear by having different email addresses. I didn't want to post a
new ticket duplicating some other persons request. This ticket here was very
close to what I'm looking for.

As was pointed out in comment #41, there is already a bug for making a ui for
having multiple identities. This bug is about making the From header editable.
 You may not see the need for having this because you *only* have 8 email
addresses. Some of us create email addresses on the fly when we are asked for
an email address by an online form. For example, my email address is
<email address hidden> and the only place I use this is in discussing mozilla.
Unfortunately, I stupidly posted it on a mozilla news group and it got
harvested, but I simply redirect all mail to that address that is not from the
mozilla bug daemon to a junk folder because I know it is spam. However, I don't
want to have to create an address for every email alias I create and I don't
even want to have to wade through a drop down of 50 email aliases to find the
one that I should use in a given context. If this bug ever gets fixed, it would
be nice to have a from address that I have entered get put in my address book
and provide auto-completion from the address book in that field. That way, when
I type in moz, it lets me accept "<email address hidden>" if I want.

> It seems that other bug is focused on signatures primarily.

No, please *read* it. Reading before making long comments is a good idea, or
you're wasting our time.

> Those headers would be customizable within the account manager interface

It's too time-consuming. Please read up in this bug.

I frequently use "dummy accounts" that never receive incoming mail. Their only
purpose is to let me edit the From field, that is otherwise uneditable.

Here is a workaround that works for me:
I made a simple Perl script that simulates a POP3 server. It accepts any
username and password whatsoever, and always reports an empty mailbox. This is
useful for advancing past Mozilla's account creation screen (which will not let
you create an account without specifying some kind of email server).

If anyone wants this script, email me at mozilla{at}krellan{dot}com and I will
send it to you.

what for, just specify any servername and tell mozilla to not automatically
check it, no need for a complicated setup of a dummy pop server

The reason I needed the dummy POP server is for an interaction with the offline
synchronize feature. When you do an Alt-FLS, Mozilla will then decide to check
every mailbox for messages, regardless of whether or not you've told it to not
automatically check mail! When starting the offline sync, if any mailbox has an
error such as an unreachable server, Mozilla will error out and refuse to
continue the sync with other mailboxes. So, the simple method of entering a
nonexistent server name will not work in this case. This is unfortunate. I
will search for another bug with this issue and file a new bug if necessary.

Another thought: I am responsible for many role accounts. Often it would be
helpful to have "reply" choose the To address as my From address. That would
save me the trouble of overriding it (or in this case reconfiguring it.)

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

Re: Comment #34 and in general. rfc2822 _does_ allow multiple from fields.

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

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

This bug is more than 2 years old and is one of the most duplicated ones. Is
there any interest in fixing this?

> Is there any interest in fixing this?

Yes, from my side, there is great interest.
I was happy when the Tunderbird 0.1 came out. But when I found that setting the
From-header still doesn't work, I immediately switched back to XFMail.

For anyone that wants to hack a dirty solution based on just xul/js files, I
posted some modifications to
http://forums.mozillazine.org/viewtopic.php?t=12190&start=15 that adds a "From"
option to the "To, Cc, Bcc, etc) drop down list in the addressing pane. It
doesn't seem like a "production" solution because it doesn't prevent me from
having two "from" lines which generates a confusing from address. However, if
you only select one from address, the hack replaces the email address in the
current identity with the one in the from address and then replaces it after the
send message completes. This gives me the functionality that I was looking for
without having to wait for a real solution to this bug. The message shows up at
the recipient with my desired email address (that can be found/completed using
the address book) and yet otherwise behaves as with the original identity. That
is, it contains my name and organization as well as copies get saved and/or sent
as the fcc fields indicate.

I don't have the environment set up to make changes to C++ code and I'm not sure
 how all of the pieces fit together. However, maybe I can propose something
that will at least get solutions talked about for this bug again.

Add an attribute to nsIMsgCompFields.idl to support an alternate "from" email
address. It may be desireable to support alternate name and/or organization as
well. Modify nsMsgCompose.cpp to the alternate email (and/or name,
organization) instead of the one supplied in the passed identity if they are
supplied.

For the UI, I think adding "From" (and possibly name and organization) clutters
the popup menu as well as the addressingWidget. Maybe a popup dialog that
appears from a menu selection under options which would allow you to set the
desired "alternate" fields of nsIMsgCompFields would be a reasonable way of
handling it.

Feel free to try the hack and/or shoot down the above suggestion.

Re comment 55, neat idea! Sadly, it doesn't work for me. The last version that
didn't break my other requirement is 1.4a. When I apply your patch, I get a
drop-down From box with ... in it (and nothing else.) From: is in the address
drop-down choice, but I can't get more than one. So I can send a message from
my address, but I can't put a To: or CC: also. Plus the File -> Close doesn't
work. Too bad I don't understand the files in the .jar.

Would someone please add this feature to Mozilla! I, too, have my own domain
and use the <email address hidden> trick. Creating multiple accounts
is NOT an option. What I want is exactly what this bug is about: being able to
manually specify the contents of the From: line during message composition.

I find it absurd that so many other mail apps, including some really puny ones,
can do this, but Mozilla can't.

It's too bad Mozilla doesn't support out-going message filters. Then I could at
least write a message filter that replaces the From: line with the contents of
the Reply-To line. That would be an acceptable work-around.

I totally agree with comment #57.

It's a pity, that an editable "From:" field is not available in Mozilla or
Thunderbird. People who suggest to create extra accounts in order to deal with
this "bug" do not get the point of the issue.

Creating mail-adresses on the fly is just one of many ways how people handle
their mail traffic, but it needs editable "From:" fields. Why is this way of
dealing with e-mail totally neglected by the Mozilla developers?

Are there any substantial arguments against implementing this feature? I haven't
heard any valid ones yet.

Eudora implements this feature hazzle-free (afer activating it in the
.ini-file), just as various other mail-clients do. The editable "From:" field in
these applications doesn't increase fraud, it doesn't confuse unexperienced
users and it works fine with other muliple account features.

As non-programmer I can just hope, that some developer appreciates the value of
this feature and shows some interest in implementing it to the otherwise great
and more than recommendable Mozilla software solutions.

Please stop with the "I agree with comment n". If you want to register your
interest in this bug, vote for it (57 people have already).

This is open-source software. If you want something fixing, fix it yourself.

To the author of comment #59:

Open source is supposed to be open to suggestions and to feedback.

The alleged "I agree" posting (comment #58) was more than that. It introduced
three common arguments, which are often brought up as reasons against the
implementation of editable "From:" fields.

An alternate program (Eudora) which incorporates the desired functionality was
named. Thus people get the chance to look at a useable implementation of the
discussed feature, if interested.

This should help not only to see, that the above mentioned arguments are not
substantial, but could also give an impression of what people actually ask for
in this bug and how it could be implemented in Mozilla.

The feature request discussed here is often misunderstood or in other cases
referred to as exotic or unnecessary, as it results from a suppposedly uncommon
way of handling emails. To prove this assumption wrong it is to a certain degree
justifiable and/or necessary to repeat the request for this feature, including
the description of one's way of handling mail as the underlying reason for the
request.

Your statement on the other hand did not contribute to the discussion of this "bug":

Hinting at the ability of voting was needless (at least regarding my person), as
you could have seen, that I already did and thus was aware of the chance to do so.

Your "fix it yourself" comment proves ignorance towards the diversity of an open
source community. Programming is not the only form of participation. Thankworthy
not many open source programmers shows your kind of arrogance, but accept
criticism and requests as what they are: a suggestion for improvement and a
chance for the implementation of possibly popular features.

I collect email from 3 different accounts.

I have two other accounts that have mail forwards placed on them so that they
forward to one of my 3 accounts that I collect mail from.

I need the ability to send email as one of five addresses. I've already voted
for this bug. Please show your support and vote for it.

Two of these accounts I do not directly collect the mail from and do not have an
associated incoming/outgoing server for them. The only way I could make
mozilla work for me was by directly editing the user.js file and making changes.

A simple drop down menu in the "From" field that has a list of email addresses
that can be added to would be really sweet. The mailer would use the default
account to send the mail but change the From field on the fly.

You want bug 44863. (Please read the bug and the bugzilla etiquette before
commenting.)

Created an attachment (id=145791)
preliminary patch

This patch is kind of a hack. It will work for the most part, but it is a UI
only patch and in order to fix this properly I need to change some C++ code. I
will try to do that this weekend.

I'm looking into adding autocompletion, but in the meantime, please try out
this patch and let me know if you guys have comments or suggestions.

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

A comment from the bug that just got duped to this one which I haven't seen
anyone mention on this one yet:

This is enough of an edge case that I think this would be a good candidate for
implementation as an extension if it's possible to implement that way.

And yes, I'm someone who's dying to have this feature (I'm a domain owner who
makes up addresses for communicating with various entities I don't trust not to
share with spammers ;) , so I don't think it's not important. :)

> This is enough of an edge case that I think this would be a good candidate for
> implementation as an extension

You mean something like this: http://www.supportware.net/mozilla/#ext2 ?

Nathan, I don't need this feature but I anyhow tested your patch. And to my
surprise, I think I like it.
The expression to test/decompose the from address needs some work to be less
strict. E.g. it should work without a realname given (I guess the question mark
has to be outside the braces) and without <>.
Also getCurrentAccountKey() now gets an empty account key.

But with that and work on autocompletition it could become nice. Are you still
working on this?

The approach of the extension mentioned in comment #66 also works nice but I
don't like to have that extra line though it could get hidden by default.

(In reply to comment #66)
> > This is enough of an edge case that I think this would be a good candidate for
> > implementation as an extension
>
> You mean something like this: http://www.supportware.net/mozilla/#ext2 ?

Ooh, I like this. I've been using it for the last week, and here's some
comments on it:

1) The resulting UI on this is *very* similar to the UI that Eudora uses for
this same purpose. I think this is a plus.
2) When replying to mail that was posted to a mailing list, it puts the list
post address in my From field. I doubt if that's desired behavior. I notice on
some lists, it asks me first. I'm guessing that it's using the domain name, and
since a lot of my lists are in the same domain as my email address, it assumes
they're me. :) Mailing lists are somewhat easy to detect (look for a List-Id
header (Mailman) or a Sender: header containing an address with "-owner" in it
(Majordomo)).
3) When I get one of the above "should I use this?" questions and hit Cancel, I
have a blank From textbox instead of having the default address in it.

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

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

David, isn't your bug resolved with #44863 ?

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

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

I have voted for this too (my first vote on bugzilla!).

I would find an editable from address in the compose window extremely useful, as
would all the staff at the company I work for. We use qmail and it allows all
users to have infinite email addresses which can help stop SPAM becoming a
problem, and also aid other filtering if necessary.

I (and most of the others) use unique addresses all the time, via web forms and
also over the telephone. I find it most useful to be able to give out a unique
address to people, but I also want to be able to send from that address without
changing my email preferences every time (and then forgetting to change them
back!). I generally use this method to protect my address at least once per day.

An example would be this;
Someone calls me from companyA regarding a product I may be interested in, and
asks for my email address.
I don't want to give them my primary address as they may SPAM it to death, so I
use their company name in the address I give them. i.e. instead of
<email address hidden> I give them <email address hidden> (postfix uses
a + instead of a = but works the same).
This normally confuses the hell out of them, but thats their problem! :-)
This allows me to receive email from them, but also block that unique address
later on if necessary. I can also see who sold my address (mostly for my own
amusement...).

My proposal would be to make the From: field in the compose window completely
editable, like that of XFMail. I cannot see any security reason for not doing
this as it is easy enough to do anyway. This would allow me to edit it on the
fly without going through any menus. I would still find having a "customise"
option in the From: field annoying (but I suppose better than nothing).

I would use this both at home and work, and so would 90% of the staff at the
company I work for. The majority of them believe being able to use unique
addresses to be extremely useful, and as we all use Mozilla for both web
browsing and email, this would be a great addition to an already superb package!

Thanks!

(In reply to comment #74)

> My proposal would be to make the From: field in the compose window completely
> editable, like that of XFMail. I cannot see any security reason for not doing
> this as it is easy enough to do anyway. This would allow me to edit it on the
> fly without going through any menus. I would still find having a "customise"
> option in the From: field annoying (but I suppose better than nothing).

Have a look at mnenhy (http://mnenhy.mozdev.org/). It is a really cool extension
and it allows you to specify an individual from header in the compose window.

I was really hopeful about mnenhy as the other extension "Temporary From on
Compose" is not exactly right and mnenhy looked to be exactly what I wanted
(along with other nifty features).

Unfortunately, upon testing this, it appears to *add* an additional From: header
and does not override/suppress the original one produced by Mozilla Mail....
which more or less makes it useless.

It also does not affect the Return-Path: header which I can understand but it
may be a nice feature to include a "header set" or something, i.e. changing From
header automatically changes Return-Path: header to the same value (or the
stripped out email address). Dunno how that would work, but will probably x-post
this to the mnenhy devs when I get a mo'.

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

So what is the best solution so far for this problem? Which extension works
best with Thunderbird 1.0.2 (if any) or which patch (if any)? Thank you.

(In reply to comment #78)
> So what is the best solution so far for this problem? Which extension works
> best with Thunderbird 1.0.2 (if any) or which patch (if any)? Thank you.

I posted back in March about this, but since then have been using Thunderbird
which pretty much does what I originally wanted.

I know I'm not telling anyone here anything they don't know, but I just wanted
to close up my post by saying I have found a solution which suits me.

In Thunderbird, although the From header in the compose window is not editable,
you can set up as many identities as you want from the Account Settings menu.
These identities are then selectable within the compose window using a list.
Also, if someone sends you an email to one of your identities, Thunderbird
automatically uses this address when you click reply so you don't need to
remember to change it yourself.

As I said, not exactly what I wanted, but it does the job very well. You only
need to set up the identity once (very quick to do) and from then on it is
available for you to use. Excellent!

(In reply to comment #79)

> As I said, not exactly what I wanted, but it does the job very well. You only
> need to set up the identity once (very quick to do) and from then on it is
> available for you to use. Excellent!

Not exactly what I want. I want a free form From: field where I can make up
identities on the fly, for my own domain for example. I don't want to create
identities for some addresses that I maybe use only once (e.g. to sign up for
an announce mailing list I would use something like this someid-product-
<email address hidden> and then never need to use this identity as I could
never post to this list).

(In reply to comment #80)
> Not exactly what I want. I want a free form From: field where I can make up
> identities on the fly, for my own domain for example. I don't want to create
> identities for some addresses that I maybe use only once (e.g. to sign up for
> an announce mailing list I would use something like this someid-product-
> <email address hidden> and then never need to use this identity as I could
> never post to this list).

Yes, sorry about that. I think I clicked the wrong thing! I was actually just
wanting to post in general, not in reply to your post.

Good luck!

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

Look at comment #68. At http://www.supportware.net/mozilla/ there are some
pretty extensions, that may be used for editing from field. But as for me, I
would prefer them in the base Thunderbird.

The "Virtual Identity" extension seems to do the trick for me:

https://addons.mozilla.org/extensions/moreinfo.php?
application=thunderbird&numpg=10&id=594

Still, it would be nice for Thunderbird to provide this functionality.

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

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

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

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

I have often missed this feature in TB. My vote for this one. So it's now 94 votes for this feature, plus lots of dupes, plus 24 votes for bug 361093...
Looks like this feature is very much wanted by users!

Actually, the Virtual Identity extension kinda means this isn't really required in the core any more IMO, but YMMV.

wanted‑thunderbird3-

Nice idea from launchpad:
> I could imagine, that the last entry in the dropdown would say
> "Edit..." or "Custom..."

I think this enhancement is still a lot needed. You can't require a user to add an identity each time he uses a new email box.

some email provider allow to aliases their account to multiple variants like gmail (account <email address hidden> could received email to <email address hidden>) or otherinbox (account @aaa.otherinbox.com could received all email to <email address hidden>). You could create one at anytime.

Thunderbird needs to allow for this kind of account to edit "on-demand" the From field and maybe create automatically an identity for them (with a description to remember creation date). It could be the same when receiving an email on a know alias pattern (TB could suggest adding this identity)

I agree it seems not adequate for standard user but "advanced" one could enabled it.

Do the same as in Kmail, please. I moved form Thunderbird to Kmail/1 in 2008 because Kmail/1 IMAP performance was magnitudes faster. I reconsidered and moved back to Thunderbird a few months ago because Kmail/1 has been replaced by Kmail/2 with degraded (understatment [1]) IMAP performance and plenty of other issues. I found Thunderbird has leapt forward (kudos!); I could add to it almost all the features I got used to in Kmail with add-ons, except the lack of ability to edit the From field for the current email only. There was an add-on [2], but unfortunately it is discontinued [3]. If somebody with the necessary skill/knowledge could update that add-on, the feature would be available to whoever needs it, although the implementation in Kmail/1 is actually a very elegant one, with the feature "hidden" and available by simply clicking into the field.

[1] <https://bugs.kde.org/show_bug.cgi?id=291006>
[2] <https://addons.mozilla.org/en-US/thunderbird/addon/tb-change-from-and-fcc-on-comp/>
[3] <http://www.supportware.net/mozilla/>

(In reply to Launchpad from comment #94)

Use Virtual Identity: https://www.absorb.it/virtual-id/

It is very good, lots of options (too complicated at times) and it's upadted on a regular basis (though not via the official addons site [1]). It currently has a problem with TB 13 but I'm sure the author will address it soon.

[1] http://blog.absorb.it/2011/09/24/whats-wrong-with-httpaddons-mozilla-org

Created attachment 8491619
Possible patch

This seems to work, it even remembers the address you entered if you save a draft and reopen it later.

Hmm... This completely removes the ability to choose from your accounts though, and I don't think that's a good idea. This is significantly harder to use. Was that your intent?

(In reply to Josiah Bruner from comment #97)
> This completely removes the ability to choose from your accounts

It wasn't supposed to... what are you seeing?

Although now the address can be edited (via keyboard), I can no longer click on the header to select from my existing accounts as you can currently.

Created attachment 8507858
87987.png

This is what I get locally... are you not seeing this?

(In reply to <email address hidden> from comment #100)
> Created attachment 8507858
> 87987.png
>
> This is what I get locally... are you not seeing this?

No, hovering over the dropmarker doesn't do anything for me.

Comment on attachment 8507858
87987.png

Ignoring the fact that the patch doesn't function properly for me, I'm still not convinced this is the right approach.

I like that we're enabling custom editing, and am not against the purpose of the bug, but I think this idea is putting too much emphasis on it. Most people will want to choose between the options they added (the drop down list), and do not want to type things in manually. However, this patch (I'm guessing, since I don't know what the actual interaction is) does not make that drop down obvious.

I think what we should do is reverse this, and show the drop down if they click anywhere other than an edit button. The edit button could go where the dropdown icon is now for example.

Created attachment 8525381
Possible patch

josiah: Ping

As for UX, I agree with Neil: Most common action would be to select from the dropdown, so that should be the big click target (most of the widget), and the free edit should be an smaller "Edit" button.

(In reply to Ben Bucksch (:BenB) from comment #104)
> josiah: Ping

The patch still doesn't work properly. On my machine absolute nothing changes. I pinged Neil about this on IRC today.(In reply to Ben Bucksch (:BenB) from comment #105)
> As for UX, I agree with Neil: Most common action would be to select from the
> dropdown, so that should be the big click target (most of the widget), and
> the free edit should be an smaller "Edit" button.

I'm confused by that slightly. Do you agree with me (which is what you outlined here), or Neil's original suggestion, which was the opposite?

Josiah, sorry, I mis-attributed. I agree with your comment 102.

Comment on attachment 8525381
Possible patch

Review of attachment 8525381:
-----------------------------------------------------------------

Okay, I do like that addresses can be edited, and don't really have an issue with it. However, it showing up when clicking the label isn't very intuitive. I suggest we simply add "Enter a custom address..." as one of the menu item options. Preferably with a separator (I'll attach a sketch to be even clearer). That way the option doesn't interfere with flow, but is still easily available.

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

This is obsolete now (and the patch fails to apply because of it).

Created attachment 8544150
Example sketch.

Here's the example. In addition, if the user deselects the field without inputting any text, we should revert the field back to being selectable (with the options).

It would also be preferable to allow clicking the drop down icon to always bring up the list, regardless of the field's current state.

(In reply to Josiah Bruner from comment #108)
> > + from = MimeHeaders_get(mdd->headers, HEADER_FROM, false, false);
>
> This is obsolete now (and the patch fails to apply because of it).

Whoops I accidentally checked that line in as part of bug 11039.

(In reply to Josiah Bruner from comment #109)
> It would also be preferable to allow clicking the drop down icon to always
> bring up the list, regardless of the field's current state.

It does on sane platforms, thus the original version always had the field editable.

Just to make sure that we're looking at the same thing here, there are other editable lists in the UI. The easiest one is the advanced attribute editor. Compose an HTML message, then go to Format - Page Colours and Background, then click Advanced Edit. On the bottom left is an editable list of commonly used attributes (background, bgcolor, text, link, vlink, alink, id, class, title, lang, dir).

(In reply to comment #111)
> It does on sane platforms

OK that was a bit harsh but I can't reproduce your problems on Windows.

(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #109)
> Created attachment 8544150
> Example sketch.

I'm not sure if the sketch UI will work out well as presented; imo it might easily create confusion and wrong assumptions about this feature.

From selector in compose UI of current release has simultaneous double function:
Select a predefined sender identity as a set consisting of
a) From-field of sent msg: John Doe <john(at)gmail.com>
b) SMTP-Server & login for sending: smtp.gmail.com, port: 465, SSL/TLS, normal password, username: john(at)gmail.com
If I understand this bug correctly, for a given(!) identity selected by user from the dropdown, we want to allow editing a) (From-field) only, but we still rely on getting b) SMTP-Server from the original identity.

"Enter a custom address...", more so at the bottom(!) of the dropdown list, wrongly suggests that user could create a new address/identity at the same level as the other identities in the list, which is not the case. Instead, the UI should reflect that we only allow window-dressing of the From-field text value within a predefined identity (which btw will not work for many commonly used mail servers, so we also need to think in terms of ux-error-prevention!).

I agree with Josiah's comment 102 (supported by Ben's comment 107):

(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #102)
> Comment on attachment 8507858
> 87987.png
>
> I think what we should do is ... show the drop down if they
> click anywhere other than an edit button. The edit button could go where the
> dropdown icon is now for example.

****************************
Tentative UI/UX proposal:
****************************

1) non-hover, non-focus:
[John <john(at)gmail.com> v]

- hide edit icon/button
- single-left-click from-selector anywhere opens dropdown (big click target for default workflow of picking predefined identity from list, as proposed by Josiah/Ben)
- double-click anywhere -> edit sender (double click does nothing useful otherwise, so it's free).

2) hover, focus:
[John <john(at)gmail.com> [/] v]

- only when hovered or focused, show a small "Edit" icon [/] (e.g. pen)
- imo per ux-natural-mapping, the correct position for this icon, as hinted by Josiah, is *inside* the dropdown (correctly implying you can edit the inner value based on prior choice in dropdown).
- clicking the "Edit" icon allows editing of From field value, either dialogue (allowing explanation of dangers involved for unsuspecting users), or inline (how do we handle ux-error-prevention then?)

3) popup (without editing):
[John <john(at)gmail.com> [/] v]
|John private <john.private(at)foo.bar> |
|John tertiary <john.tertiary(at)asdf.com> |
+------------------------------------------------------+

- if user hasn't edited anything, clicking anywhere on from-selector outside "Edit" icon will open the normal and unmodified popup
- imo we should *not* advertise this feature more by offering a dedicated action row inside the dropdown, ux-error-prevention for default users: many smtp servers will reject alter...

UX-error-prevention / Pref

1) General interest and usefulness of this feature seem to have declinied: Last duplicate of this bug filed 2006, 8 years ago. Only 4 supportive comments since 2005. As we speak, many common email-providers do no longer allow defining random "From" values, to prevent spam/spoof.

2) Otoh, adding this feature by default has a big error potential, as editing sender can prevent users from successfully sending their message (which they will only notice after sending). Which makes this a case of UX-error-prevention.

3) I conclude from 1) and 2) that this feature should be preffed-off by default, and I suspect hidden pref might suffice for the type of advanced users who have their own domain to tweak senders at random.

I think it's a reasonable idea to default this feature to "off". If the pref is hidden, maybe a double-click on the From should ask if user wants to enable the pref? This would be a context-sensitive way to expose this feature, which defaults to "off".

Another use-case for this feature is adding a "+suffix" to the username so replies can be processed accordingly.

Created attachment 8551328
Backend changes

While you bikeshed over the UI, let me get the backend changes reviewed (or post-facto reviewed in the case of the second hunk).

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.