Open Bug 36482 Opened 21 years ago Updated 3 years ago

Initial identity based on rules

Categories

(MailNews Core :: Composition, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: helpwanted)

Problem

The multiple identity feature is nice, but the initial identity selection
doesn't work very well for me. I use several servers (e.g. at my bucksch.org
provider and on my proxy), which consolidate all incoming mails to one account.
As a result, always the same initial identity is used.

I don't think, my case is very special.

Yes, I can change the identity later in the composition window, but
- it is extra work and failure-prone
- the sig currently doesn't change (filed bug 36480 about that)


Proposed solution

It would be easy (well understood, not necessarily quick to implement) to select
the correct one, e.g. based on the "To" address. I suggest to use a system
similar to filters (preferably even reuse the code) as critera, prefilled with a
rule, which emulates the current behaviour.

Pine >= 4.10 (IIRC) has a concept very similar to identities, called "Roles".
They are selected roughly the way I proposed above. I think however, we can be
more powerful with selecting by filters (and using identites of course, which
are already more powerful).
Alec, do you think, it would be possible to use out existant filter code
(backend and UI) for selecting identites?
Severity: normal → enhancement
well, currently we select it based on your "current" folder. (if it doesn't work
now, we should fix it - it worked in NS's beta 1)

I think that's 'good enough' for now, personally.
I don't think we need to delve into the filter/search code though...it might be
faster just to use one of our address extraction routines to pull out the email
address and try to find an identity that matches.

I have a bug on that last one somewhere.
> I think that's 'good enough' for now, personally.

"For now" - agreed. "good enough" in general - no. As I said, this will propably
be a common request for more advanced users (and who else needs multiple
identites?).

Selecting based on TO (comparing with from addresses of identities) might help
in some cases, but not all (maybe not even most).
E.g. I use <mozilla.news@bucksch.org> for posts to the mozilla mailing lists. I
don't appear at all in the recipient headers.
Wait, so how would we handle that case? what header would we look at? 
Status: NEW → ASSIGNED
Target Milestone: --- → M22
I tell ya, I don't even want to sign up for any part of THIS feature - partly
because it's definately not on my list of work priorities, partly because it
doesn't really interest me as a feature, sorry.

I'm going to reassign to nobody & mark helpwanted.
Assignee: alecf → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
> Wait, so how would we handle that case? what header would we look at?

"X-Loop: mozilla-mail-news@mozilla.org"

Clearing MILESTONE due to reassign.
Target Milestone: M22 → ---
*** Bug 83249 has been marked as a duplicate of this bug. ***
I am definitely for a solution where you have different "roles".
There are a few ways you could accomplish this:
1. Every IMAP-folder can have its own from-header.
2. Multiple "roles" for one account.
3. Global roles for all accounts.

I can say that I am virtually hindered to send mail with Mozilla since the
from-addess is fixed. Have a catch-all on my domain peope.net and a
.procmailrc-recipe that places mail in different folders according to the
destination.

This is a list of roles:
pgsql@mydomain.net  (for mailinglists)
apache@mydomain.net (for mailinglists)
mozilla@mydomain.net (My identity here)
peope@mydomain.net  (Base inbox)


You can all see the issues here. Eg cannot send stuff to the
PostgreSQL-mailinglists.

I tried to create a new account with same server, same user, different email but
it was denied since the user/server was the same as another one.

Another problem arises when creating multiple accounts for the same account.
There will be requests for new mail from each account (Lots of overhead).

Best workaroung seem to be to create multiple bogus pop3-accounts.

Can we do something about this.
(Not too unfamiliar to contributing work myself) =)
> I tried to create a new account with same server, same user, different email but
> it was denied since the user/server was the same as another one.

See my comment in bug 83249.

> Can we do something about this.
> (Not too unfamiliar to contributing work myself) =)

Of course, you are welcome to work on it.
*** Bug 90475 has been marked as a duplicate of this bug. ***
Bug 90475 has a suggested UI, and also provides an alternate (more precise?) specification.
With more and more spam around, more and more people are dealing with it by
creating a separate email address at their own domain for each person/entity
they communicate with. That way, if some company sells the email address you
gave them, you just block it forever.

The solution doesn't need to be as elaborate as suggested in Bug 90475. All that
is needed for these purposes is for the From field to be overridden with the
contents of the To field of the incoming email.
Product: MailNews → Core
*** Bug 292172 has been marked as a duplicate of this bug. ***
Blocks: 228980
*** Bug 216098 has been marked as a duplicate of this bug. ***
Bug 200872 has a patch (now obsoleted for bitrot) which implemented selection of the identity in a reply based on a property in the folder where the original message resides.
QA Contact: lchiang → composition
I agree with Craig in Comment #12. I also create addresses on-the-fly. However when a reply is received to an address of which no identity is defined, Thunderbird selects a different identity of the account that received the message, even if that identity does not match the To: address.
Instead I would expect the "main" address from the account to be used if no valid match is found.

There are some extensions that try to solve this problem (such as Virtual Identity) but they do not succeed completely and are not all actively developed.
Comment 12's suggestion does not work, for reasons that I explained in the description for Bug 264770 - most email lists don't have the recipient's email address in the "To:" field.  Instead, email lists often include the email list's address in the "To:" field.  This works very simply and elegantly in Eudora with its filters, because the identity used to reply to a message can be set based on any filter criteria, on any header line (standard or user-defined).  This problem, and many others, are solved easily.  Thunderbird claims to have "advanced filters," but unfortunately, the marketing folks at Mozilla seem to think "advanced" means basic, since T-Bird's filters are painfully basic. :(

Hopefully with Quallcom giving Eudora over to the Thunderbird open source community, this problem will solve itself, assuming that Thunderbird eventually adopts filters that are comparable in capability to Eudora's (i.e. hopefully Thunderbird will finally have "advanced filters").
Product: Core → MailNews Core
No longer blocks: 228980
Comment 15 is the only solution that is worth considering: selection of the identity in a reply/forward based on a property in the folder where the original message resides. The "from Address", the "signature" and the formatting type ie html or text, should simply be based on the settings from the account that the folder is in that contains the message being replied to, or forwarded from.
Wrong. There are lots of other situations where that isn't sufficient. See e.g. first paragraph of initial description. If I reply from the Inbox, and the From selection is only based on the folder, I am sure to send the wrong From most of the time.
To cater for different setups/users then it would be sensible to have some options that the user could select in their preferences. I am similar to Ben in that I consolidate all incoming mails to one server, but then I drag each email into the relevant account's inbox. When I reply or forward from there the From, Signature and Formatting needs to be taken from the account the email is sitting in, not some random X-account setting. 
So the options could be:
1 Use X-account
2 Use the account the email is in
3 Use the To address
4 ?
David, this bug is clearly defined (please don't cloud the issue by sidetracking this bug): The user should be able to define the From: address using filter rules and the Filter dialog, similar as we have it for incoming mails.

In fact, bug 11039 asks to apply filters to outgoing mail. This bug here would then be just another filter "action" (the current filter dialog already allows different actions), including move to folder, mark as junk, delete etc.. "Set From: to foo@bar" would then be just another filter action just like "move to folder FooCorp".
Depends on: 11039
Surely the idea of multiple accounts is that an account is setup for each 
email identity that the user has, ie Home, work, charity etc. 
Then it make sense to keep the mail relating to that identity in folders 
in the relevant account, ie any work related emails would be kept in the 
work\inbox, or work\sent etc. 
Emails could get there by either downloading from different pop servers, 
or by dragging from another account if all incoming mails are consolidated to one server.

Composing a new message when a certain account is highlighted works correctly, 
ie the correct formatting is selected (text/html) and the correct from address 
is selected. 

When it comes to replying or forwarding a message that is highlighted, 
it should work the same way, BUT IT DOESNT !!

Please correct me if I am wrong, but I believe the solution is blatantly obvious and very simple:
1 Ignore the X-Account-Key, or add an option to ignore the X-Account-Key
2 When replying to a message, or forwarding a message, use the same subroutine that creates a new message. 
   That correctly Opens a new edit window
   Uses the correct formatting 
   Uses the correct signature, CC and Bcc addresses
   Uses the correct From address 

To cater for different setups/users then it would be sensible to have some options 
that the user could select in their preferences.
See Also: → 355520
You need to log in before you can comment on or make changes to this bug.