Interesting, I'll play with this in a test environment later on and let you know what I find - I say interesting because it is something I can elaborate on in the webadmin for a domain since many have asked about how to divide and distribute info between departments.

I first reported this problem about three years ago.  As I recall, it was acknowledged.

If I have mailing lists "list@host" and "biglist@host" where "list@host" is a member of "biglist@host" then, when mail is received for "biglist@host" the core process shows "To: list@host" but the mail is not sent to the members of "list@host".  This always occurs if one list has, as a member, a list whose name is a substring of its own name.

I can avoid the problem with aliases but that's cumbersome.

 - Vince

Hmm, could you specify how your listname and list address are built. Does your aliasing resemble my solution (http://community.pmail.com/forums/thread/1421.aspx) for multiple lists with nearly the same name but different domains?

Hmm, could you specify how your listname and list address are built. Does your aliasing resemble my solution (http://community.pmail.com/forums/thread/1421.aspx) for multiple lists with nearly the same name but different domains?

It's pretty straightforward. From my most recent test:

Address (as seen in top level MailList dialog): wxyz
Title (full address): wxyz@vefatica.net
Members: xyz@vefatica.net

Address (as seen in top level MailList dialog): xyz
Title (full address): xyz@vefatica.net
Members: vefatica (local)

When the core processes mail to wxyz@vefatica.net I see "To: xyz@vefatica.net" but no mail is sent to xyz's member.

I've conducted this test about 6 times, with different names.  It's always the case that if list1's name is a substring of list2's and list1 is a member of list2 then the members of list1 don't get mail accepted for list2.

 - Vince
 

To be honest, I think the not being able to have lists being members of lists is a safety precaution. The message is in process of being routed either to a local mailbox or queued off externally. If it was to be queued again to another mailing list you would have a potential loop.

How did you manage to get it working with aliases?

[quote user="Peter Strömblad"]

To be honest, I think the not being able to have lists being members of lists is a safety precaution. The message is in process of being routed either to a local mailbox or queued off externally. If it was to be queued again to another mailing list you would have a potential loop.

How did you manage to get it working with aliases?

[/quote]

But you can have mailing lists as members of mailing lists (it would be sadly limited if you couldn't). At work we I have a hierarchy of lists: the "everyone" list contains all other lists; the "allfaculty" list contains the "faculty" (*) and "ptfaculty" lists; the "allgrads" list contains the "tagrads" and "ntagrads" lists (and so on).  Only the innermost lists have individuals as members.  It works well (almost).  Can you imagine the chore of maintaining the collection if lists were not allowed as members?

(*) There's only a problem when a member list name is a substring of the parent list name.  So, above, there's a problem with "faculty" being a member of "allfaculty".  To work around this, the "allfaculty" list actually contains the "phony" and "ptfaculty" lists and an alias points "faculty" to "phony".

As you suggested the problem could easily be related to an attempt at suppressing loops.  Whatever the reason, it doesn't work correctly.

 - Vince



 

I misspoke a moment ago.  The collection of lists is nested.  "Everyone" doesn't contain all other lists (as I has said); it contains only lists at the next level ("allfaculty", "allgrads", et c.).

 - Vince