Closed Bug 87987 (editablefrom) Opened 23 years ago Closed 9 years ago

Make From header editable per-message (from the Composer)

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(thunderbird45+ fixed, thunderbird46 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 45.0
Tracking Flags:
Tracking Status
thunderbird45 + fixed
thunderbird46 --- fixed

People

(Reporter: novalis, Assigned: neil)

References

(Depends on 1 open bug,
URL
)

Details

(Whiteboard: [relnote-thunderbird])

Attachments

(8 files, 17 obsolete files)

87987.png
53.25 KB, image/png
Details
Example sketch.
40.31 KB, image/png
Details
Backend changes [checked in, comment 120]
2.12 KB, patch
jcranmer
: review+
Details | Diff | Splinter Review
Fixed fix [checked in, comment 124]
2.02 KB, patch
jcranmer
: review+
Details | Diff | Splinter Review
Screenshot of normal dropdown (Linux)
24.30 KB, image/png
Details
Screenshot of editable field (Linux)
7.76 KB, image/png
Details
With variable placeholder [checked in - comment 200+201, TB 45]
14.39 KB, patch
mkmelin
: review+
Details | Diff | Splinter Review
tests v2 [checked in - comment 213, TB46][checkin Aurora 45, backout, checkin again - comment 215, 218, 231]
7.37 KB, patch
mkmelin
: review+
mkmelin
: approval-comm-aurora+
Details | Diff | Splinter Review 
Often, I want to send a message that appears to come from someone else.  For
example, I respond to e-mails directed to wikiaccount@worldforge.org, and I want
my messages to appear to come from that address.  Setting the reply-to header is
nice, but it's not exactly what I want - my personal address is still associated
with WF mail.

It should be possible to change the From address, just like it is possible to
change To, CC, Reply-to, etc.  It should also be possible to choose from a list
of commonly used addresses (for example, 99% of my outgoing mail will be my
primary address, novalis-testing@novalis.org, wikiaccount@worldforge.org, or
(soon) licensing@gnu,org).  

A more general version of this would allow adding/changing arbitrary headers.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.,
"microsoft-poll-Aug2001@mydomain.com"). This is a valid e-mail because I've set
up anything@mydomain.com 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
Assignee: ducarroz → 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. ***
Summary: From header should be configurable per-message → [RFE] Make From header editable per-message (from the compose window)
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.
Summary: [RFE] Make From header editable per-message (from the compose window) → Make From header editable per-message (from the Composer)
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.
QA Contact: sheelar → esther
*** 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. ***
Alias: editablefrom
*** 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.
Assignee: varada → sspitzer
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 need to make a UI for adding 
that type of account and set the options accordingly.

Thanks for your feedback on this matter.
> 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 wikiaccount@worldforge.org, 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
mozilla@gevers5.com 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 "illa@gevers5.com" 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.
Blocks: majorbugs
Would someone please add this feature to Mozilla!  I, too, have my own domain
and use the address-du-spammer@mydomain.com 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.)
Attached patch preliminary patch (obsolete) — — Splinter Review 
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.
Blocks: 221652
*** Bug 221652 has been marked as a duplicate of this bug. ***
No longer blocks: 221652
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 ?
Product: MailNews → Core
*** 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
myaddress@mydomain.com I give them myaddress-companyA@mydomain.com (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. ***
URL: http://mnenhy.mozdev.org | http://w...
Whiteboard: Workarounds in comments #66 and #75
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-
announce@mydomain.com 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-
> announce@mydomain.com 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.
Whiteboard: Workarounds in comments #66 and #75 → Workarounds in comments #66, #75 and #84
No longer blocks: majorbugs
*** 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. ***
Assignee: sspitzer → nobody
QA Contact: esther → composition
Blocks: 361093
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!
Flags: wanted-thunderbird3?
Actually, the Virtual Identity extension kinda means this isn't really required in the core any more IMO, but YMMV.
Product: Core → MailNews Core
wanted‑thunderbird3-
Flags: wanted-thunderbird3? → 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 aaa@gmail.com could received email to aaa+something@gmail.com) or otherinbox (account @aaa.otherinbox.com could received all email to something@aaa.otherinbox.com). 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.
Blocks: 582179
No longer blocks: 582179
Yuv added the following comment to Launchpad bug report 357864:

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

-- 
http://launchpad.net/bugs/357864
(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
Attached patch Possible patch (obsolete) — — Splinter Review 
This seems to work, it even remembers the address you entered if you save a draft and reopen it later.
Attachment #8491619 - Flags: feedback?(josiah)
Attachment #8491619 - Flags: feedback?(ben.bucksch)
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?
Attachment #8491619 - Flags: feedback?(josiah)
(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.
Attached image 87987.png — 
This is what I get locally... are you not seeing this?
Attachment #8507858 - Flags: feedback?(josiah)
(In reply to neil@parkwaycc.co.uk from comment #100)
> Created attachment 8507858 [details]
> 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 [details]
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.
Attachment #8507858 - Flags: feedback?(josiah)
Attached patch Possible patch (obsolete) — — Splinter Review 

        Attachment #8525381 -
        Flags: feedback?(josiah)

    
    

    
  
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 [details] [diff] [review]
Possible patch

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

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

        Attachment #8525381 -
        Flags: feedback?(josiah)

    
    

    
  

      
      
      
      

        Attached image
          
        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 [details]
> 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 [details]
> 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 altered from-fields, especially when you change the email address
- consider if the entire feature should be preffed-off by default, again ux-error-prevention

4) popup (with/after editing):
[Johnny Edited <john(at)fakemail.com>             [/] v]
|*John <john(at)gmail.com>                             |
|John private  <john.private(at)foo.bar>               |
|John tertiary <john.tertiary(at)asdf.com>             |
+------------------------------------------------------+

- after manual editing, we need to offer an easy way of reverting to the original identity whose from-sender was edited: offer as first entry in the dropdown, with some indication (icon, bold, etc.) that this the currently used identity (only with edited from).

5) Context menu
+--------------------+
|Edit this sender    |
|Copy                |
|Paste               |
+--------------------+

- optionally for this bug, but recommended, implement a simple context menu on the from-selector
- Edit this sender -> edit sender (dialog/inline)
- Copy: Copy the current value of sender, either original  "John <john(at)gmail.com>" or edited "Johnny Edited <john(at)fakemail.com>"
- Paste: Paste clipboard text to become the new edited value of sender
- Copy and Paste might need better strings to indicate what they do

    
    

    
  
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.

    
    

    
  


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

        Attachment #8551328 -
        Flags: review?(Pidgeot18)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Possible patch (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #8525381 -
        Attachment is obsolete: true

        Attachment #8553148 -
        Flags: ui-review?(josiah)

    
    

    
  
Comment on attachment 8551328 [details] [diff] [review]
Backend changes [checked in, comment 120]

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

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

This hunk seems unnecessary?

        Attachment #8551328 -
        Flags: review?(Pidgeot18) → review+

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Test fix (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #8561373 -
        Flags: review?(Pidgeot18)

    
    

    
  
Comment on attachment 8561373 [details] [diff] [review]
Test fix

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

::: 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 <from@tinderbox.invalid>",

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

    
    

    
  


  

        Attachment #8561373 -
        Attachment is obsolete: true

        Attachment #8561373 -
        Flags: review?(Pidgeot18)

        Attachment #8562431 -
        Flags: review?(Pidgeot18)

        Attachment #8562431 -
        Flags: review?(Pidgeot18) → review+

    
    

    
  
Comment on attachment 8553148 [details] [diff] [review]
Possible patch

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

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 “barackobama@usa.gov” 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.

        Attachment #8553148 -
        Flags: ui-review?(josiah) → ui-review-

    
    

    
  
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 neil@parkwaycc.co.uk 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 'awesomeme@me.com` address, but when my friends try to email me at the address, it doesn't show up in my Gmail account"

And that's when we're all whacking our heads on our desks. :)

    
    

    
  
(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
> “barackobama@usa.gov” 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: info@paypal.com "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
> > “barackobama@usa.gov” 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: info@paypal.com "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)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Possible patch (obsolete)
        — 
          — Splinter Review
      

    


  
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?

        Attachment #8572084 -
        Flags: ui-review?(josiah)

    
    

    
  
(In reply to neil@parkwaycc.co.uk from comment #133)
> Created attachment 8572084 [details] [diff] [review]
> 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...

    
    

    
  
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 josh+amazon@gmail.com or amazon@josh-family.org.
It is only for your own email addresses. Impersonating other people may be subject to punishment by law."

    
    

    
  
Comment on attachment 8572084 [details] [diff] [review]
Possible patch

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

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

        Attachment #8572084 -
        Flags: ui-review?(josiah) → ui-review-

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot showing the moved menuitem (obsolete)
        — 
      

    


  

    
  
Depends on: 1135610

    
  

        Attachment #8572084 -
        Attachment is obsolete: true

    
  

        Attachment #8574154 -
        Attachment is obsolete: true

    
    

    
  


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

    
    

    
  


  
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 john+filterword@gmail.com 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 [details]?

(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.
Flags: needinfo?(josiah)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        TB UI - Revised patch (obsolete)
        — 
          — Splinter Review
      

    


  
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.

        Attachment #8491619 -
        Attachment is obsolete: true

        Attachment #8553148 -
        Attachment is obsolete: true

        Attachment #8491619 -
        Flags: feedback?(ben.bucksch)

    
    

    
  
(In reply to neil@parkwaycc.co.uk from comment #154)
> (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.

File a bug.
Flags: needinfo?(josiah)

    
    

    
  
Comment on attachment 145791 [details] [diff] [review]
preliminary patch

This seems to be superseded by Neil's UI patch.

        Attachment #145791 -
        Attachment is obsolete: true

    
  

        Attachment #8551328 -
        Attachment description: Backend changes → Backend changes [checked in, comment 120]

    
  

        Attachment #8562431 -
        Attachment description: Fixed fix → Fixed fix [checked in, comment 124]

    
  
Assignee: nobody → neil
Status: NEW → ASSIGNED

    
  

        Attachment #8583150 -
        Attachment description: Revised patch → TB UI - Revised patch

    
    

    
  
Please do not forget some test :) One in test-newmsg-compose-identity.js should work.
Flags: in-testsuite?

    
    

    
  
Neil, have you filed the bug for the theme change for menulists (comment 156)?

On the other hand, I can make you a mozmill test for the feature here, if you are not familiar with that.

    
    

    
  
(In reply to aceman from comment #159)
> Neil, have you filed the bug for the theme change for menulists (comment 156)?
Sorry, I forgot to do that. Filed bug 1159316.

> On the other hand, I can make you a mozmill test for the feature here, if
> you are not familiar with that.
That would be a correct assumption.

    
    

    
  


  

        Attachment #8583150 -
        Attachment is obsolete: true

        Attachment #8599196 -
        Flags: review?(josiah)

    
    

    
  
To the one-time message, please add (see comment 142) at least:
"This allows you to use a custom author email address depending on their recipient, for example josh+amazon@gmail.com or amazon@josh-family.org."

    
    

    
  
as the developer of "virtual Identity" extension, currently struggeling with the changes, I can only say: Yes, put this feature into the core. This has to be part of a modern mail-client and the extension is a major hack which required changes allover thunderbird to work. It's really hard to maintain and surely an extension is not the right place to solve this issue. Do it now the "real way" - I will be happy to stop the development of such a nightmarish extension and use this feature I always missed in native thunderbird.

    
    

    
  
Comment on attachment 8599196 [details] [diff] [review]
TB UI - updated after bug 1135610

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

This seems to work for me. I applied this on top of bug 318495 to write some tests.

So there is no way to make the menulist non-editable again? Is that intentional?

::: mail/components/compose/content/messengercompose.xul
@@ +897,5 @@
>            <hbox id="top-gradient-box">
>              <hbox align="center" pack="end" style="&headersSpace.style;">
> +              <toolbarbutton id="identityLabel" label="&fromAddr.label;"
> +                             accesskey="&fromAddr.accesskey;"
> +                             oncommand="MakeFromFieldEditable();"/>

Shouldn't this also be command="cmd_customizeFromAddress" ?

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

This text feels kinda strange to me. I am not sure translators will also understand what it means. Maybe "Customize sending address..."

    
    

    
  

      
      
      
      

        Attached patch
          
          
        tests (obsolete)
        — 
          — Splinter Review
      

    


  
Mozmill test for this feature in Thunderbird.

    
    

    
  
(In reply to aceman from comment #164)
> So there is no way to make the menulist non-editable again? Is that
> intentional?

What would the UX be for that, particularly once you've changed the from address, saved it as draft, and then edited the draft?

    
    

    
  


  

        Attachment #8599196 -
        Attachment is obsolete: true

        Attachment #8599196 -
        Flags: review?(josiah)

        Attachment #8615410 -
        Flags: review?(mkmelin+mozilla)

    
    

    
  
Comment on attachment 8615410 [details] [diff] [review]
TB UI - updated after bug 1166206

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

There's still some issues that needs to be sorted out here.

- on linux (at least) the "From:" is grayed out so you can't almost see it unless hovering
- once in the input field enter doesn't make move out of the box as one would expect
- then clicking on From again resets the previous thing you entered
- allows setting From to something that's not a valid address
- doesn't accept adding a second (comma separated) From, and doesn't warn  

- I think the UI needs to be more hidden. While a cool feature, for the vast majority of mails you wouldn't use it after all. As is you'd hit it very often by mistake from the "From:" button. Could it be a context menu command for the From selector, and/or selectable as Options | Custom From Address? We need it in a menu somewhere anyway for keyboard accessibility.

- could use a placeholder for when you've removed all the text from the From input field; something like "Enter custom from address, e.g. [full email with an +example@ address. "

::: mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties
@@ +129,5 @@
>  chooseFileToAttachViaCloud=Attach File(s) via %1$S
>  
>  ##
>  windowTitlePrefix=Write:
> +customizeFromAddressWarning=If your e-mail provider supports it, this feature allows you to make a one-off minor alteration to your From address without having to create a new Identity in Account Settings. For example, you may have several e-mail aliases, or you may want change your display name.

"this feature" is unclear. "the Custom From feature" perhaps?

Why is Identity capitalized. And why even mention the account settings? We already said it was for one-off cases. 

Might as well mention that it's primarily for +aliases, as gmail supports those. Other use cases are probably handled by setting up the other identity.

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

+ ellipsis

I don't think this menu option should hide even if we're already in that mode. It's confusing how to get back to editing then.

        Attachment #8615410 -
        Flags: review?(mkmelin+mozilla) → review-

    
    

    
  
(In reply to Magnus Melin from comment #168)
> - on linux (at least) the "From:" is grayed out so you can't almost see it
> unless hovering
I'll just drop that change then; trying to fix up TB CSS isn't a good use of my time.

> - once in the input field enter doesn't make move out of the box as one
> would expect
Good point.

> - then clicking on From again resets the previous thing you entered
Another good reason to get rid of that change.

> - allows setting From to something that's not a valid address
What would you suggest, running it through the header parser and if it doesn't like it then set it back to the last selection (note: not the previous value; that's harder)?

> - doesn't accept adding a second (comma separated) From, and doesn't warn  
That wouldn't be a valid address anyway.

> - I think the UI needs to be more hidden. While a cool feature, for the vast
> majority of mails you wouldn't use it after all. As is you'd hit it very
> often by mistake from the "From:" button. Could it be a context menu command
> for the From selector, and/or selectable as Options | Custom From Address?
> We need it in a menu somewhere anyway for keyboard accessibility.
(Ben doesn't want it in the Options menu)

> - could use a placeholder for when you've removed all the text from the From
> input field; something like "Enter custom from address, e.g. [full email
> with an +example@ address. "
Nice idea thanks.

> > +customizeFromAddressWarning=If your e-mail provider supports it, this feature allows you to make a one-off minor alteration to your From address without having to create a new Identity in Account Settings. For example, you may have several e-mail aliases, or you may want change your display name.
> "this feature" is unclear. "the Custom From feature" perhaps?
Does the dialog title not make that clear?

> Might as well mention that it's primarily for +aliases, as gmail supports
> those. Other use cases are probably handled by setting up the other identity.
Yes, but this is a prompt, so I didn't want to get bogged down in details (like you create identities in account settings... oops!)

> > +<!ENTITY customizeFromAddress.label "Customize From Address">
> + ellipsis
Doesn't open a dialog...

> I don't think this menu option should hide even if we're already in that
> mode. It's confusing how to get back to editing then.
Back to? How do you leave editing?

    
    

    
  
(In reply to neil@parkwaycc.co.uk from comment #169)
> (In reply to Magnus Melin from comment #168)
> > - on linux (at least) the "From:" is grayed out so you can't almost see it
> > unless hovering
> I'll just drop that change then; trying to fix up TB CSS isn't a good use of
> my time.

And should be addressed in bug 1159316.

    
    

    
  
(In reply to neil@parkwaycc.co.uk from comment #169)
> > - allows setting From to something that's not a valid address
> What would you suggest, running it through the header parser and if it
> doesn't like it then set it back to the last selection (note: not the
> previous value; that's harder)?

Hm, preferably leave what the user entered until we have something valid. Could alert the user that what he entered is not valid, and let him choose to fix the problem or stop customizing (=go back to default). 
 
> > - doesn't accept adding a second (comma separated) From, and doesn't warn  
> That wouldn't be a valid address anyway.

From RFC 5322:
   The from field consists of the field name "From" and a comma-
   separated list of one or more mailbox specifications. 
 
> > - I think the UI needs to be more hidden. While a cool feature, for the vast
> > majority of mails you wouldn't use it after all. As is you'd hit it very
> > often by mistake from the "From:" button. Could it be a context menu command
> > for the From selector, and/or selectable as Options | Custom From Address?
> > We need it in a menu somewhere anyway for keyboard accessibility.
> (Ben doesn't want it in the Options menu)

Well, I do :)
And that's *way* more hidden than having the From be a clickable button.

> > > +customizeFromAddressWarning=If your e-mail provider supports it, this feature allows you to make a one-off minor alteration to your From address without having to create a new Identity in Account Settings. For example, you may have several e-mail aliases, or you may want change your display name.
> > "this feature" is unclear. "the Custom From feature" perhaps?
> Does the dialog title not make that clear?

Apparently I never noticed it. BTW, it's now a one time dialog, maybe better to have a "don't show this dialog in the future" option there? You might end up there by mistake otherwise, and then forget until next time.

> > > +<!ENTITY customizeFromAddress.label "Customize From Address">
> > + ellipsis
> Doesn't open a dialog...

AFAIK, ellipsis doesn't care if it's a new dialog or not. It's "requires further input to do something useful"

> > I don't think this menu option should hide even if we're already in that
> > mode. It's confusing how to get back to editing then.
> Back to? How do you leave editing?

Probably never left, but that's unclear if you don't actually edit anything. I'd just have liked the menu option to still be there and clicking it would make focus get back to the editable address. 

One other thing: maybe the editable address should get selected too? One of the biggest problems now is that you don't easily realize that focus shifted and things are editable, unless you have used it before and expect it.

    
    

    
  
(In reply to Magnus Melin from comment #171)
> One other thing: maybe the editable address should get selected too?
Huh, it does for me.

    
    

    
  
(In reply to comment #169)
> (In reply to Magnus Melin from comment #168)
> > - allows setting From to something that's not a valid address
> What would you suggest, running it through the header parser
Actually the header parser will turn almost anything into an address. If you leave off the <>s then it assumes that the whole string is the email address. (I think leaving off the @ is also legal; it just sends to the SMTP server's default domain, if that exists.)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Addressed review comments (obsolete)
        — 
          — Splinter Review
      

    


  
Well, some of them, at least.

        Attachment #8615410 -
        Attachment is obsolete: true

        Attachment #8616760 -
        Flags: feedback?(mkmelin+mozilla)

    
    

    
  
Comment on attachment 8616760 [details] [diff] [review]
Addressed review comments

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

Overall looks much better. 

The info dialog should not have a title with "..."
One issue I came across saving draft (to an account that's not really working) and cancelling save will leave the From selector disabled

::: mail/components/compose/content/messengercompose.xul
@@ +687,5 @@
>                         fileHereLabel="&fileHereMenu.label;"/>
>            </menu>
> +          <menuseparator/>
> +          <menuitem type="checkbox" command="cmd_customizeFromAddress"
> +                    accesskey="*customizeFromAddress.accesskey;"/>

i assume this is meant as a todo

        Attachment #8616760 -
        Flags: feedback?(mkmelin+mozilla) → feedback+

    
    

    
  
(In reply to Magnus Melin from comment #175)
> (From update of attachment 8616760 [details] [diff] [review])
> > +                    accesskey="*customizeFromAddress.accesskey;"/>
> 
> i assume this is meant as a todo

No, it's a typo, sorry.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Addressed more review comments (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Bah, stupid autocomplete.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Addressed more review comments (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #8616760 -
        Attachment is obsolete: true

        Attachment #8628816 -
        Attachment is obsolete: true

        Attachment #8628817 -
        Flags: review?(mkmelin+mozilla)

    
    

    
  
Comment on attachment 8628817 [details] [diff] [review]
Addressed more review comments

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

Yeah this is getting close to landable.
I'd at least like error handling for when you enter something that's not an email address at all, and placeholder text for when you remove all the prefilled text.

Another thing that is a bit confusing is that you don't see what account is used really send from (to know what settings and which folders will be used). But maybe we can leave that for a followup...

::: mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties
@@ +130,5 @@
>  
>  ##
>  windowTitlePrefix=Write:
> +customizeFromAddressTitle=Customize From Address
> +customizeFromAddressWarning=If your e-mail provider supports it, Customize From Address allows you to make a one-off minor alteration to your From address without having to create a new identity in Account Settings. For example, if your From address is John Doe <john@gmail.com> you may want to change it to John Doe <john+doe@gmail.com> or John <john@gmail.com>.

probably want to use @example.com

@@ +131,5 @@
>  ##
>  windowTitlePrefix=Write:
> +customizeFromAddressTitle=Customize From Address
> +customizeFromAddressWarning=If your e-mail provider supports it, Customize From Address allows you to make a one-off minor alteration to your From address without having to create a new identity in Account Settings. For example, if your From address is John Doe <john@gmail.com> you may want to change it to John Doe <john+doe@gmail.com> or John <john@gmail.com>.
> +customizeFromAddressIgnore=Don't remind me about this again

"notify" instead of "remind" perhaps?

        Attachment #8628817 -
        Flags: review?(mkmelin+mozilla) → feedback+

    
    

    
  
It's been over 14 yrs since the enhancement was filed :-)

    
    

    
  
(In reply to Magnus Melin from comment #180)
> I'd at least like error handling for when you enter something that's not an
> email address at all
Please define "not an email address at all". Note that the Account Manager doesn't stop you from putting utter garbage into your email fields.

> placeholder text for when you remove all the prefilled text.
Fair enough.

> Another thing that is a bit confusing is that you don't see what account is
> used really send from (to know what settings and which folders will be
> used). But maybe we can leave that for a followup...
It should still be the selected account in the list (when you drop it down).

> probably want to use @example.com
Does that domain support custom aliases?

> > +customizeFromAddressIgnore=Don't remind me about this again
> 
> "notify" instead of "remind" perhaps?
I'll copy this:
bigFileHideNotification.check=Never notify me of this again.
Flags: needinfo?(mkmelin+mozilla)

    
    

    
  
(In reply to neil@parkwaycc.co.uk from comment #182)
> (In reply to Magnus Melin from comment #180)
> > I'd at least like error handling for when you enter something that's not an
> > email address at all
> Please define "not an email address at all". Note that the Account Manager
> doesn't stop you from putting utter garbage into your email fields.

Good question. So ok, let's not add error handling.

> > probably want to use @example.com
> Does that domain support custom aliases?

Well it doesn't actually deliver mails anywhere so "support" is debatable.
Flags: needinfo?(mkmelin+mozilla)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Revised patch (obsolete)
        — 
          — Splinter Review
      

    


  
My placeholder text isn't very creative I'm afraid...

        Attachment #8628817 -
        Attachment is obsolete: true

        Attachment #8658290 -
        Flags: feedback?(mkmelin+mozilla)

    
    

    
  
Comment on attachment 8658290 [details] [diff] [review]
Revised patch

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

(Slightly bitrotted.)

::: mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd
@@ +305,5 @@
>  <!-- Title for the address picker panel -->
>  <!ENTITY addressesSidebarTitle.label "Contacts">
>  
> +<!-- Identity editable menulist placeholder -->
> +<!ENTITY msgIdentity.placeholder "Customize From Address">

How about "Enter custom From address".

Or even better "Enter custom From address to be used instead of [users-original-mailbox]"

        Attachment #8658290 -
        Flags: feedback?(mkmelin+mozilla) → feedback+

    
    

    
  
Any chance of finalizing this shortly? Would be a nice feature for tb45.

    
    

    
  
Yes let's get this finished and landed.

          tracking-thunderbird45:
          --- → +

    
    

    
  
I'm using the latest Seamonkey, where it is already possible to edit the From: entry in a message composition window... <confused> Have some of the proposed changes already landed?

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39

    
    

    
  
(In reply to Magnus Melin from comment #186)
> Any chance of finalizing this shortly? Would be a nice feature for tb45.

Sorry, I must have overlooked that you were waiting on me for this again.

(In reply to Mason from comment #188)
> I'm using the latest Seamonkey, where it is already possible to edit the
> From: entry in a message composition window... <confused> Have some of the
> proposed changes already landed?

The backend changes landed ages ago, and I separately landed a simplified interface for SeaMonkey, which was useful for testing purposes.

    
    

    
  
So Neil, will you be submitting a revised patch for Thunderbird prior to the string deadline?
Flags: needinfo?(neil)

    
    

    
  
(In reply to Kent James from comment #190)
> So Neil, will you be submitting a revised patch for Thunderbird prior to the
> string deadline?

I will try, but I was busier than expected yesterday and today, and I will be busy again tomorrow too, and I'm still struggling with man flu...
Flags: needinfo?(neil)

    
    

    
  
I suggest we do a quick review of what we have, either I or Magus could clean it up, and we land that before the deadline. We can always do followups.
Flags: needinfo?(rkent)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Revised patch (obsolete)
        — 
          — Splinter Review
      

    


  
This just has the simpler change for now, in case I don't get a chance to finish the more complex version.

        Attachment #8658290 -
        Attachment is obsolete: true

        Attachment #8697719 -
        Flags: review?(mkmelin+mozilla)

    
  
Flags: needinfo?(rkent)

    
    

    
  
Comment on attachment 8697719 [details] [diff] [review]
Revised patch

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

I think this is ok to land. It has a bit of a rough touch somehow but it does what it's supposed to and it's a nice feature.

::: mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties
@@ +130,5 @@
>  
>  ##
>  windowTitlePrefix=Write:
> +customizeFromAddressTitle=Customize From Address
> +customizeFromAddressWarning=If your e-mail provider supports it, Customize From Address allows you to make a one-off minor alteration to your From address without having to create a new identity in Account Settings. For example, if your From address is John Doe <john@gmail.com> you may want to change it to John Doe <john+doe@gmail.com> or John <john@gmail.com>.

still think this should use @example.com

        Attachment #8697719 -
        Flags: review?(mkmelin+mozilla) → review+

    
    

    
  
aceman: the tests you created https://bugzilla.mozilla.org/attachment.cgi?id=8606679 no longer applies, could you dust them of?
Flags: needinfo?(acelists)

    
    

    
  
It's probably because the tests are intended to be applied on top of my other bug (as written in comment 164). But if at least the patch here has a chance to go in I try to rewrite them...
Flags: needinfo?(acelists)

    
    

    
  
My local build is not working right now so I can't test the patch and adapt the test (unfortunatelly it is based on a highly modified version of the test from bug 318495.
Can we push this in before the string freeze and push the test later?

    
    

    
  
Comment on attachment 8697892 [details] [diff] [review]
With variable placeholder [checked in - comment 200+201, TB 45]

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

Yes, let's land this, with with the @example.com domain instead of @gmail in the sample text.
We can land aceman's tests later.

        Attachment #8697892 -
        Flags: review?(mkmelin+mozilla) → review+

    
  
Keywords: checkin-needed

    
  

        Attachment #8697719 -
        Attachment is obsolete: true

    
    

    
  
https://hg.mozilla.org/comm-central/rev/0f98648f72ae
Keywords: checkin-needed
Target Milestone: --- → Thunderbird 45.0

    
  

        Attachment #8697892 -
        Attachment description: With variable placeholder → With variable placeholder [checked in - comment 200]

    
    

    
  
Forgot to fix the sample email addresses in the message so here they are:
https://hg.mozilla.org/comm-central/rev/8a5605536c6d

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot showing the problems. (obsolete)
        — 
      

    


  
Hey guys, what you landed there doesn't quite work.

If I do "Edit as New Message" on a message I sent before, I see this in the From field:
=?UTF-8?Q?J=c3=b6rg_Knobloch?= <jorgk@jorgk.com>
The original from field was: From: =?ISO-8859-1?Q?J=F6rg_Knobloch?= <jorgk@jorgk.com> produced back then with TB 24. Fails just the same with a modern message with this original header:
From: =?UTF-8?Q?J=c3=b6rg_Knobloch?= <jorgk@jorgk.com>

That's the first bug. The second bug is that I'm automatically placed in to the "Customize From Address" mode. Why?

And thirdly, there is something wrong with the text display in the field. Anything below the baseline of the text is cut off.
Flags: needinfo?(neil)

    
    

    
  
Same set of problems when I save a draft and then edit it again.
BTW, the cutting off of the text at the baseline always happens in "Customize From Address" mode.

I'm using Earlybird 45.

    
    

    
  
(In reply to Jorg K (GMT+1) from comment #202)
> Created attachment 8698483 [details]
> Screenshot showing the problems.
> 
> And thirdly, there is something wrong with the text display in the field.
> Anything below the baseline of the text is cut off.

Please file a bug about this. I can then fix it.

    
    

    
  
Richard: This bug here is not done yet. Apparently a more complex version is yet to come (comment #193) and also a test (comment #198). I'd prefer to implement the entire feature in one bug and not spread it across multiple bugs. Do you agree?

    
    

    
  
No, this is a CSS bug and has nothing to do with the JS implementation. Then the appearance is fixed and this bug here can focus to functionality improvement.

    
    

    
  
I know that this is a CSS bug. But a heap of CSS was tossed here without replacement. My opinion still is that one single bug delivers one piece of new functionality. Of course there can be multiple patches for CSS, icons, code, tests, etc. It's not convenient to split the new functionality into multiple bugs since this will cause dependencies which would have to be taken into account for the uplift.

Alternatively we close this bug and open a new one:
Make From header editable (part 2, missing bits: CSS, test, etc.)

I'll let the original authors decide what they want to do.

    
    

    
  
(In reply to Jorg K (GMT+1) from comment #202)
> If I do "Edit as New Message" on a message I sent before, I see this in the
> From field:
> =?UTF-8?Q?J=c3=b6rg_Knobloch?= <jorgk@jorgk.com>
Huh, I thought I decoded the header before using the value. Please file a new bug?

> That's the first bug. The second bug is that I'm automatically placed in to
> the "Customize From Address" mode. Why?
Because the misdecoded address doesn't match any of your known From addresses.

> And thirdly, there is something wrong with the text display in the field.
> Anything below the baseline of the text is cut off.
I don't see that bug in SeaMonkey, but then again we use sane^H^H^H^Hboring CSS.
Flags: needinfo?(neil)

    
    

    
  
I'm not sure why you need a new bug for this, but since two gentlemen insist, I will just obey:
Bug 1232735.

    
    

    
  


  
Updated tests that no longer depend on bug 318495.

        Attachment #8606679 -
        Attachment is obsolete: true

        Attachment #8698483 -
        Attachment is obsolete: true

        Attachment #8700423 -
        Flags: review?(mkmelin+mozilla)

    
    

    
  
Comment on attachment 8700423 [details] [diff] [review]
tests v2 [checked in - comment 213, TB46][checkin Aurora 45, backout, checkin again - comment 215, 218, 231]

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

LGTM, r=mkmelin

        Attachment #8700423 -
        Flags: review?(mkmelin+mozilla) → review+

    
    

    
  
Thanks.
Keywords: checkin-needed

    
    

    
  
https://hg.mozilla.org/comm-central/rev/d0e6db81879d
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 8700423 [details] [diff] [review]
tests v2 [checked in - comment 213, TB46][checkin Aurora 45, backout, checkin again - comment 215, 218, 231]

[Triage Comment]
After nighlty looks green we should uplift these tests to aurora45 as the main feature landed there.

        Attachment #8700423 -
        Flags: approval-comm-aurora+

    
    

    
  
Looks like the test is giving mixed results, strange, sometimes fails on opt, other times on debug:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=d0e6db81879d
https://treeherder.mozilla.org/#/jobs?repo=comm-aurora&revision=a4907013150f

(Terribly sorry for not reading/following Magnus' comment "after nightly looks green" and uplifting this too impatiently. I'll fix it when gets fixed on C-C.)
Flags: needinfo?(acelists)

    
    

    
  
Yes, I can see it in the logs on try build. Strangely the menupopup is not showing up. Usually I have these kind of problems (intermittently) on my local run (Linux), but this time all is fine and the failures are on the server. And they are almost permanent, so I'll check it out.

    
  
Depends on: 1237565

    
    

    
  
Backed out from Aurora, too many oranges ;-(
Sorry, shouldn't have landed it there in the first place.
https://hg.mozilla.org/releases/comm-aurora/rev/aadc5f56de79
Flags: needinfo?(acelists)

    
    

    
  
Since this is a patch that we really want in TB 45, trying to get it into the 45 train ASAP is worth doing. You should evaluate the breaking tests, and consider disabling them if the results are not real.

    
    

    
  
And you really need to set the status flags, those are used in inquiries of what needs landing in branches.
Flags: needinfo?(rkent)

    
    

    
  
Now you are seeing why us drivers like to see bugs that do not span multiple releases.

From your backed-out message in comment 218, it is not clear which patch you backed out. At this point, it would be worth modifying all of the r+ patch descriptions to add [checked-in] to those that are checked in, and perhaps [backed-out] for those that are backed out.

For the status, keep in mind that searches for patches needing landing will not find this bug if there are partial landings, and the status-thunderbird45 is set to fixed. So I would remove the status-thunderbird45 fixed if there are any remaining patches to land. Also, the whole bug should not be fixed if there are patches pending. So only set the FIXED and status- fixed once all patches have landed, that is the safest.
Flags: needinfo?(rkent)

    
    

    
  
One other thing, once the patches have landed, set the TARGET-MILESTONE to be when the complete feature landed (so for example a relnote would be meaningful), and set the status-thunderbird flags for the whole bug based on the feature landing (ignoring the tests). This is all a compromise, it is really best to do new bugs for additional patches that land after a gecko number is rolled.

    
    

    
  
Sorry, the main feature got "crash landed" on the last day before branch day. I was *not* involved. I didn't set any flags. I only fixed an immediate bug in what was landed in bug 1232735. So I'm the good guy here. The only mistake I made was to land the test on Aurora as soon as Magnus gave the OK, sadly ignoring his comment #214:
*After nighlty looks green* we should uplift these tests to aurora45 as the main feature landed there.
So I backed it out. I'm really not responsible for the "cross milestone issue" or setting something to fixed which isn't. I will now go and change the patch descriptions.

        Attachment #8697892 -
        Attachment description: With variable placeholder [checked in - comment 200] → With variable placeholder [checked in - comment 200+201, TB 45]

        Attachment #8700423 -
        Attachment description: tests v2 → tests v2 [checked in - comment 213, TB46][checked into Aurora 45 and backed out - comment 215 + 218]

    
    

    
  
Yes, the intention was to land the tests days after the main patch so that it could go into aurora and all patches be in TB45. If that seems not achievable, I am fine with leaving this closed and moving the tests to another bug.
OR we could leave the tests on trunk and make a patch for Aurora 45 only that disables the failing part of the test. I can do that small patch here that goes only to Aurora.
I specifically propose to NOT back out the test from trunk because that is the only place where we can see the failure. Nobody can yet reproduce it locally so the information could get lost.

    
    

    
  
(In reply to :aceman from comment #225)

> I specifically propose to NOT back out the test from trunk because that is
> the only place where we can see the failure. Nobody can yet reproduce it
> locally so the information could get lost.

Personally I am not happy with this philosophy, though I agree it is the current approach. What this does is create work for everyone who has to land a patch, to track down this issue and convince themselves it is a known problem. It would be better to have a philosophy of disabling known broken tests, and keeping a separate list of disabled tests.

If you can convince yourself that the breakage is merely a testing artifact and not real, then clearly the answer is to backout the test and file a bug to fix the test.

    
    

    
  
I agree we should be more aggressive about backing out patches that cause failures, though it's sometimes temping to wait.
There's not much point (except for more pressure to fix it quickly) having it on trunk perma failing. You'll see the failure on try just as well. 

Let's do the test issues in another bug though.

    
  
Depends on: 1238264

    
    

    
  
(In reply to Magnus Melin from comment #227)
> Let's do the test issues in another bug though.

Yes, the fix is in bug 1237565.

    
    

    
  
Marking keyword so this is not forgotten.
Keywords: checkin-needed
Whiteboard: Workarounds in comments #66, #75 and #84 → [Workarounds in comments #66, #75 and #84][check in 'tests v2' into aurora when bug 1237565 is approved for aurora]

    
    

    
  
Don't worry, I'm watching bug 1237565. The Aurora landing is on my "to do" list.
I find the checkin-needed somewhat confusing, I've seen "Whiteboard: [checkin-needed comm-aurora]" instead. Again, I'll do it together with the patch from the other bug.
Keywords: checkin-needed

        Attachment #8700423 -
        Attachment description: tests v2 [checked in - comment 213, TB46][checked into Aurora 45 and backed out - comment 215 + 218] → tests v2 [checked in - comment 213, TB46][checkin Aurora 45, backout, checkin again - comment 215, 218, 231]
Whiteboard: [Workarounds in comments #66, #75 and #84][check in 'tests v2' into aurora when bug 1237565 is approved for aurora] → [Workarounds in comments #66, #75 and #84]

    
  
Whiteboard: [Workarounds in comments #66, #75 and #84] → [relnote-thunderbird]

    
    

    
  
Thanks! This solves one mayor hurdle towards using a personal domain to fight spam by handing out unique email addresses. To address the next hurdle, I've opened a new feature request to allow automatically setting the "from:" field based on the recipient email address when responding to email.
See Also:  → 1251934

    
  
See Also:  → 1252079

    
    

    
  
This is excellent news. 

I (QuickFolders Addon) have a special feature for setting default To / Cc headers based on folder, now I can extend this with a From: Address feature. This way I could make mailing list specific communication even simpler and safer. Excellent!!

    
  
Depends on: 1254666
Depends on: 1268789

    
    

    
  
Hi Thunderbird,

By enabling from header editable, you have simply created a new security loophole. Any user can edit the email id at from field and misuse the this feature against it's victim. So please have a look into this and tell me how can we overcome this vulnerability ?

Thanks,
OM

    
    

    
  
Hi OM,
any user could do the same even before this feature in the UI.

Have you actually tried it? Does your SMTP server allow sending out such faked email?

    
    

    
  
(In reply to :aceman from comment #236)
> Hi OM,
> any user could do the same even before this feature in the UI.
> 
> Have you actually tried it? Does your SMTP server allow sending out such
> faked email?

Hi aceman,

Yes I have tried this in gmail's account option by changing the reply address. But can you please share me the steps on behalf of which you are saying "any user could do the same even before this feature in the UI". Also please tell me that how we can disable such faked email in smtp server.

Thanks,
OM

    
    

    
  
Even before editable from you could always go to account settings and set up an identity with whatever email you want. If it's allowed or not is up to the SMTP server, and how to enforce it in the SMTP server depends on what server you're using. (I have no details on that.)

    
    

    
  
(In reply to OM from comment #237)
> Yes I have tried this in gmail's account option by changing the reply
> address.

Is the Reply address the same as the From address? I don't know the gmail UI.

> But can you please share me the steps on behalf of which you are
> saying "any user could do the same even before this feature in the UI".

Prepare a normal message where you are the in sender (From) field. Click "Send Later".
Look up your Outbox (Unsent messages) folder. It now contains the unsent message. Rightclick the folder -> Properties. See the Location field for where the folder is stored on your system. Close TB. Open that file in a text editor. Locate the message you just composed and edit any field/header as you wish. Then start TB and send out Unsent messages.

> Also
> please tell me that how we can disable such faked email in smtp server.

This is a job of the server operator to forbid relaying such faked emails through his server. That is why if a server is found to be sending out spam/faked emails, it is blacklisted on other servers and you will not receive emails from users of the server. See e.g. https://en.wikipedia.org/wiki/Open_mail_relay .

Of course, there is a difference whether server allows replaying messages of any users, or only legitimate (authenticated) users. Even if only authenticated, it is a second step of protection whether it allows those to fake the From header in their messages. But even if it does, as I said, the new UI does no make things worse (does not allow anything that wasn't possible before). I'm sure you have seen tons of spam with faked sender address (even your own). So TB does not allow anything new.

    
    

    
  
There is nothing in the SMTP protocol to prevent forgeries, and things like mail lists depend on that.  Various hacks to detect and block forgeries are just that - hacks (spf, dkim, dmarc) and generally break maillists if enforced strictly.  This is no different that snail mail - you can write whatever from address you want on the envelope, and you can put whatever letterhead you want on the letter inside as well.  If you want people to know you actually sent the message, digitally sign it - thunderbird supports that well and I've been doing it for a long time, and with mutt/pgp many years before that.

You don't even have to manually edit a saved, unsent, message, just go into Tools/Account Settings/Manage Identities in the main setting window for an account and create whatever identity you want to be able to use.  The editiable header function is just a convenience for transient addresses (e.g. people who have their own domain and use unique user parts for sites that require an email address to use them).

    
    

    
  
The way you implemented this has made Postfix rule reject_sender_login_mismatch useless. We have it implemented in our company to stop coworkers from forging their sender address. That rule checks "MAIL FROM" with SASL login. But the way you implemented this, Thunderbird sends correct "MAIL FROM" so it results in positive verification, but after DATA it sends "From: .... <whatever_user_entered_in_sender@blablabla.com>. So finally mail is sent with forged From address.

Please fix this asap.

    
    

    
  
(In reply to Adam Miauczyński from comment #241)
> The way you implemented this has made Postfix rule
> reject_sender_login_mismatch useless. We have it implemented in our company
> to stop coworkers from forging their sender address. That rule checks "MAIL
> FROM" with SASL login. But the way you implemented this, Thunderbird sends
> correct "MAIL FROM" so it results in positive verification, but after DATA
> it sends "From: .... <whatever_user_entered_in_sender@blablabla.com>. So
> finally mail is sent with forged From address.
> 
> Please fix this asap.

Adam, if you do not check that message header matches SASL login, then your users can inpersonate each other using other mail clients, including telnet/netcat/openssl s_client/etc. So, problem is at your server end. Therefore it is YOU who needs to fix your system asap.

    
    

    
  
This is a really incomplete implementation. "MAIL FROM" is used by the SMTP server as a bounce address - it makes no sense to unintentionally set the bounce address differently than the senders identity. As a result, hiding your permanently stored identity is also not working, because the SMTP server will convert the "MAIL FROM" address into the "return path" header and provide this address to any possible spammer as well.

I checked the code but from my point of view the implementation is incomplete. There must be some code added into "nsSmtpProtocol::SendHeloResponse", currently the new identity is only stored in the messageComposeFields, which are not accessible (?) by the asynchronous sending process (my knowledge about the scope of the current changes is not enough to provide a patch),

Please reopen this ticket till the implementation is complete!

    
    

    
  
Please open new bugs for the issues found (and make them block this one). Nothing can be fixed here nearing comment 250.

    
  
Depends on: 1294027

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: