yeah yeah, I know ... it's me again... here's some ideas for Mailman2, and note these objects could be stored in a nice fancy object database :-)

---- ramblings begin

Ok, here's the 5 minute concept... think of it as modeling-light.

Two types of objects:

  * List object
  * Subscriber object

There is a many-many relationship between Lists and Subscribers, meaning obviously that Lists can contain many subscribers, and Subscribers can contain many lists. This creates a concern for clean-up given circular references. Need to think through this.[1]

Now, the best way to understand this is to deal with a message coming in, and how does it get exploded into the subscribers necessary:

First, you know who the mailer sent it to (say listA), but then you parse through the To:/CC: headers looking for other lists, making a note of them. If there are no other lists (local lists, not remote lists) identified then proceed with the normal delivery, no reason here to compare Message-Id: with those stored.

However, if another local list is discovered (listB) then duplicate-supression should be run. What this requires is exploding the message into all of its subscribers, and matching that with the subscribers of listB, if no overlap, short-circuit to normal delivery. But, if you do have overlap, then for each overlap, check the subscribers 'recent-ids' attribute for the current message's attribute, if it doesn't exist, append it, and send the message out. If it does exist, delete the recipient from the list passed to the MTA.

Seems simple, though I'm sure I've glossed over a billion and one things.

--- Footnotes [1] This can probable be fixed by making sure that you break the link manually rather than depending on garbage collection. Or maybe weak lists? When you delete a list, scan the subscribers, looking for reverse links, and break them, then you delete the list. Same thing for the deletion of a subscriber.

-- | Christopher Petrilli | petrilli@amber.org