Open Bug 40301 Opened 22 years ago Updated 7 months ago

Support nested mailing lists for Address Book ("list within a list", add/create inside, within another containing email list)


(MailNews Core :: Address Book, enhancement)

Not set


(Not tracked)


(Reporter: esther, Unassigned)


(Blocks 3 open bugs, )


(Whiteboard: [GS] nab-mlist)

Using builds 2000-05-22 on win98, mac and linux we currently don't support 
creating a List within a List.  I don't see this mentioned in the spec whether 
we want to support the 4.7 behavior or not support it at all.

Currently in 4.7 you can create a List within a List but it's a little 
First, you have to select the target List (not the parent address book) in the 
left pane when clicking New List button (note: the drop down in the new list 
dialog doesn't show lists only Address Books).   It looks as though you are 
creating this sub list in the selected parent address book, but it is actually 
added as a List of the selected target List and as a top level List for the 
parent address book.

If we are going to support this in 4.7, are we going to have the same behavior 
as 4.7 mentioned above?

Assigning to jglick first for comment, reassign to Candice if this is going to 
be supported.
QA Contact: lchiang → esther
Reassign to Kmurray for decision of whether we need to do this feature.  
Personally, I don't think its that critical.  And the 4.x implementation is very 
confusing so we'd have to come up with a different one.
Assignee: jglick → kmurray
The only problem I might see is if when we migrate a 4.7 profile or import a 
4.7 abook what would happen to the list within a list?  Does it become just a 
top level list of the parent address book?
I would say yes. Given how unclear it is in 4.x to do this (and how unclear the 
feedback that you have done it is), I would bet a list within a list isn't that 
IMO - The creation of a new list within a list using the Seamonkey Address 
Book is not critical. I would not spend the effort.

However, as pointed out below, data loss is bad. If a user has created a list 
within a list in 4.7, we should try to preserve the data. I just tried this in 
4.7x, and the sublist is presented both as a top level list under the parent 
address book, and as a member of the parent list. When moving from 4.7 to 
Seamonkey, ideally, we would preserve the sublist as a top level list under the 
parent address book, and expand the parent list to include all of the entries of 
the sublist.
I agree that this isn't that common. Accepting and setting to Future.
Target Milestone: --- → Future
Changing severity value to enhancement.
Severity: major → enhancement
QA Contact: esther → pmock
Blocks: 45893
*** Bug 45893 has been marked as a duplicate of this bug. ***
No longer blocks: 45893
QA Contact: pmock → fenella
QA Contact: fenella → nbaca
Keywords: 4xp
Summary: [Feature]Are we going to support a List within a List for Address Book → [RFE] Support a List within a List for Address Book
*** Bug 98167 has been marked as a duplicate of this bug. ***
Whiteboard: nab-mlist
*** Bug 133459 has been marked as a duplicate of this bug. ***
I disagree with the severity enhancement. Reason: Business segments needs this
feature (that's why we have opted for different email client than Moz in my
institute). If not implemented, Moz. is no real alternative to be considered by
this segment in the future.
Blocks: 136757
*** Bug 147918 has been marked as a duplicate of this bug. ***
Marking nsbeta1 to make the address book more robust and 4.x supported this feature.
Keywords: nsbeta1
*** Bug 154528 has been marked as a duplicate of this bug. ***
For me this bug is very important, and the argument that the list hierarchy in
4.7 is ambiguous and is therefore not to be duplicated is specious. The fact is
that pine and other e-mail programs in the UNIX world have supported this
feature for years. Anyone who's been using e-mail for more than a few years has
probably had occasion to create lists within lists, and under 4.7, you could do
that easily and consistently. And on the matter of inconsistency, downgrading
this bug effectively means the introduction of another inconsistency, in that
Mozilla and Netscape claim to be able to import LDIF files, and yet they are
unable to preserve  the addresses contained in even a two-level hierarchy, never
mind the structure of the hierarchy itself. Mozilla does not, in fact, correctly
import LDIF files. The result in my case is that every time I add an address, I
have to put it in as many as five lists, where before I was putting it in just
one list. 
This is an irritating omission for us. Even the UNIX cmdline mailers support
nested aliases (via ~/.mailrc).

Functional aliases are often created by grouping disparate organisational groups
of people. These groups often have their own alias. Having to type in multiple
aliases everytime I want to send an email to this "functional" group is bloody
*** Bug 172041 has been marked as a duplicate of this bug. ***
Should address lists "owned" by an address book? Currently they are, which means
that addresses "owned" by another address book would be duplicated in the
address book "owning" the list.

The ability to have lists which can utilise address (and lists) from different
address books is very useful. This is also true for addresses from LDAP... which
currently duplicate the address.

This duplication is confusing when updating personal information, as you have to
keep updating each copy of the address (very error prone) and can lead to using
incorrect information.
Of course Mozilla should support lists within lists. Eudora does, Entourage
does, Outlook does, Outlook Express does, pine does, and Netscape 4.x does. I
don't know of any mail software that doesn't. 

This is causing bug 151814

Also, the strange behavior in the original post is something that I do NOT
experience with Netscape 4.8 on the Mac - a list is always at the the address
book level, and it can easily contain other lists just by dragging and dropping.
There is no duplication. Please don't base a new feature on bug in some versions
of Netscape 4.x

It is a critical feature for any large organization to have lists that can
contain other lists in addition to addresses. With the advent of the Calendar
project Mozilla could actually begin to challenge Outlook, but not as it stands
with such a limited address book. 
*** Bug 180104 has been marked as a duplicate of this bug. ***
Assignee: kmurray1115 → putterman
reassigning to sspitzer
Assignee: putterman → sspitzer
Keywords: nsbeta1nsbeta1-
Nominating again. Comment# 18 states that many mail applications already support
this feature. If Mozilla wants users to convert to Mozilla then this should be
Keywords: nsbeta1-nsbeta1
Mail triage team: nsbeta1-
Keywords: nsbeta1-
Keywords: nsbeta1
Frankly, I do not understand the "nsbeta-". All major and minor mailclients
support the lists of lists. This feature is crucial for business use.

(Actually, this is the only reason why our institution supports/recomends users
to install Outlook or Pegas and not Mozilla&Netscape6). 

I feel that this bug also blocks any solution of bug 133459 , 
see bug 133459, comment 6 . 
I strongly support the opinion in comment #24 that this feature is crucial for
business use. Please fix it.
*** Bug 159590 has been marked as a duplicate of this bug. ***
I agree with the general business sentiment expressed for this bug,
especially by Calum Mackay.

For business users who are trying to build hierarchical lists to
distribute information to different groups it is very annoying. In
fact I'm resorting to setting up majordomo lists to enable me to
do this when I'd be quite happy to have it local.

However, for me this is still just at enhancement level. It's a
feature that would make my use of Mozilla easier, but the lack of
it will not encourage me to use a different mail tool.
Many of us out there use e-mail lists for various non-business
activities. For instance, I have political, humor and Egyptology
mailing lists. Having to flatten my hierarchy of mailing lists, 
and then add different names to some blend of 10 different lists,
is a real pain. 

But I would argue that just about anyone who's been doing e-mail 
for 10 years or more has by now built up a hierarchy of mailing 
lists, and is inconvenienced at the very least by the lack of 
hierarchy. And note that the feature has been in UNIX for more 
than 20 years now. Why is it so hard to put it in Netscape?

Unfortunately, I have to use mail programs on multiple platforms: IRIX, 
Macintosh, Windows and Linux, and am forced to use Netscape/Mozilla
because no other combination of browser and mail runs across all these 
platforms. Otherwise, I would have switched by now. 

*** Bug 211761 has been marked as a duplicate of this bug. ***
*** Bug 222617 has been marked as a duplicate of this bug. ***
Modifying summary to increase findability.
Summary: [RFE] Support a List within a List for Address Book → Support a List within a List for Address Book (nested, inside)
Blocks: 227212
Assignee: sspitzer → bienvenu
*** Bug 161426 has been marked as a duplicate of this bug. ***
*** Bug 151814 has been marked as a duplicate of this bug. ***
Blocks: 92345
Should a separate request be opened for this feature in Thunderbird, or will
this one cover both products?
it would cover both products. The work is almost all in the backend address book
Product: Browser → Seamonkey
For those who are after 4.5 years tired waiting for this feature: Just randomly
pick any other existing mailclient, I cannot find any serious product without
this feature. And I doubt that Santa Claus will bring a fix to us this year.
Can we get from Santa at least "nsenterprise+"?
>> Just randomly pick any other existing mailclient

I am about to do that. This is one of the features I have be waiting to get
added and 4.5 years in long enough. I switched to MozMail/TB because it offered
security features that I couldn't find in other email clients at the time. But
the rest of world has caught up and these security features can now be found in
other email clients that don't lack such features such as nested email
groups/lists. After using Thunderbird and MozillaMail prior to that for the past
couple of years I am close to switching to Courier Email. 
Blocks: 133459
Flags: blocking-seamonkey1.0a?
Nice to have, but we won't push out any release for that, not even a developer
tesing release like SeaMonkey 1.0 Alpha.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: nbaca → addressbook
Duplicate of this bug: 382575
Nested lists are possible in the linux version of thunderbird 2.0 but not in the windows version. So I guess it would be not so difficult to fix it.
I've tested it in TB 1.5 in windows and it's possible to create nested lists.

So, somewhere we loose this usefull feature.
This now works in the Mac version of Thunderbird 2 as well. Is it fixed but someone forgot to close the  bug? 
Seems to be already implemented in Seamonkey 1.1.x
I've got it working in Thunderbird in Windows Vista Ultimate.  

I created a nested list by first opening the properties window of the outer list.  Then I started to type the name of the nested list in the addresses field, just like any other email address I want to add to the list.  

Thunderbird opened a popup list box showing addresses and lists that began with the same chars I typed.  I selected the name of the list I wanted to nest and the rest of that list's name was copied in the address field. Once again this is consistent with the way it works for individual addresses.

I was able to test it by addressing a new message to the outer list, pressing "Send Later", and then going to the "Unsent" folder to view the message.  Thunderbird has correctly expanded both the outer list and nested list to the addresses they both contained.

I test changes, too.  Any changes/additions/deletions I made to the nested list were also correctly resolved by Thunderbird when it expanded the lists in a sent message's recipient field.

There is one hitch but it is not a show stopper.  In the process of nesting a list inside another one, Thunderbird creates an individual card entry with the same name as the nested list.  

It's not a list itself - if you double-click it you get a card's properties, not a list's properties.  But it must not be deleted because if you do, you will also deleted the nested list entry in the outer list!

The end result is that you wind up with a bunch of nested lists that work, but for each nested list you get an individual card with the same name.  Thus there are duplicate list names in the address book which must be retained.

This can be confusing if you want to change the members of a nested list but don't know which of the two names to double-click.  Pick the wrong one and you get a window showing card properties instead.  

There is a way to tell which is which.  If you fill in the "Description" field for a mailing list, it will be displayed in the address book as the email address of the name that is NOT a list.  

Ugh.  But it works even though it's a very clumsy workaround.  So if you must have nested lists, and if your setup is anything like mine, it has a good chance of working for you too.

This should make it simple for Mozilla to implement error-free nested lists.  All they have to do is suppress the display of those duplicate addresses created every time a list is nested.

I can't write with an economy of words unfortunately.  I hope you can figure out from this note how to do what I did.  If you can't, it's got nothing to do with you, that's fer shure.

You can see it being discussed, along with another explanation, here:

Good luck, 
Big Al Mintaka
(In reply to comment #45)
> This should make it simple for Mozilla to implement error-free nested lists. 
> All they have to do is suppress the display of those duplicate addresses
> created every time a list is nested.

No, that is not the correct fix. Although you have semi got it working, that is more due to bugs in the current system. The architecture is not properly set up to support nested lists correctly. Some of this is being addressed in bug 413260, but your fix is definitely not what we want to do.
(In reply to comment #46)

>The architecture is not properly set up to support nested lists correctly.
>Some of this is being addressed in bug 413260, but your fix is definitely 
> not what we want to do.

I stand corrected.  I know nothing about Thunderbird's architecture, so I should be reporting only what's broken and what I have working - rather than say things like "it should be easy to...".  I'll store this one for future reference.

As far as the snip above goes, does that mean that nested lists may be supported in the future?  I wasn't able to sift through that bug's page or the dependency tree to find anything I understood.

At his point my only concern is that I currently have nested lists set up in Thunderbird and don't want to lose them without warning.  If you advise me not to use them for the time being, I'll do so.

Thanks for your time in reading my previous post and responding, 
Big Al Mintaka
Blocks: 423488
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3.0a1?
3.0alpha1 is a time-driven release, definitely doesn't block that.  I'd be interested in hearing thoughts from Standard8 and clarkbw on how important it should be for Thunderbird3.
Flags: blocking-thunderbird3.0a1? → blocking-thunderbird3.0a1-
As per discussion with Standard8, not blocking, but might be wanted for Thunderbird3.
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
I'm not currently planning on doing this; reassigning to nobody. I hope this falls out of the ab reworking...I don't think it would be hard to do, in either mork or sqlite - just have a list row that is a list alias instead of an e-mail address, and expand recursively (but not infinitely :-) )
Assignee: bienvenu → nobody
Product: Core → MailNews Core
Duplicate of this bug: 460878
Priority: P3 → --
Target Milestone: Future → ---
Duplicate of this bug: 500051
This worked fine in TB2.  I have several lists which contain other lists, and sent to them all the time.

Now, in TB3, it has broken; when sending to one of my top-level lists results in the error "sublistname <sublistname> is not a valid e-mail address because it is not of the form user@host.  You must correct it before sending the e-mail."

Very annoying to have to recreate and flatten my entire list hierarchy, not to mention maintain multiple occurrences of list members.
Windows 7 Home Premium x64 using TB3.0.3 sending to ntlworld (virgin media) mail server gives slightly different message: "An error occurred while sending mail. The mail server responded: Invalid address syntax. Please check message recipient <the nested list name> and try again."

Forgive me, I'm new to this. But Comment 50 (21 months ago) mentions "ab reworking" - is the address book mechanism actively being reworked? If so, when is it likely to appear supporting address list within address list - a feature in such common use that it is almost taken for granted?

What caused it to stop working in TB3?
(In reply to comment #54)
> What caused it to stop working in TB3?

good question. I found several bugs reported yesterday, and previously incorrectly closed one. And I didn't get as far as being able to answer that question. So I have a small collection of bugs to consolidate in the next day or two, and then hopefully someone will be able to fix it and get released into a future 3.0.x version. stay tuned.

and, the rework is unrelated as far as I know.
(In reply to comment #53)
> This worked fine in TB2.  I have several lists which contain other lists, and
> sent to them all the time.

DeWrek, see bug 542947 comment 7. No one there as reported doing the regression work - perhaps you could do so, or convince someone else to do it?
Happy to help if I can. I have a test rig (Win XP) on which I can do some testing (I don't use email from that system). I don't have compliers. I may need some debug aids, to trap what TB is actually sending out.

How can I assist?
The regression of this functionality which occurred in TB3 is documented in bug
I think this one can be closed, as the original request was to add the feature 10 years ago.  That was done, but subsequently broke.
Duplicate of this bug: 567113
Duplicate of this bug: 624294
I would like to nest a mailing list into another one. It is an important feature for me.
Whiteboard: nab-mlist → [GS] nab-mlist
With dozens of duplicates, about time to include the technically correct term "Mailing list" and some other relevant search words in summary... ;)
Summary: Support a List within a List for Address Book (nested, inside) → Support nested mailing lists for Address Book ("list within a list", add/create inside, within another containing email list)
Flags: wanted-thunderbird3?
See Also: → 337479
Duplicate of this bug: 1538095

Wasn't this implemented in bug 1287726?

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