Did you ever get an answer to this? I was short of round tuits so left this in the inbox, but maybe you already have the answers.
sunil soprey writes:
Do you plan to reintroduce the de-duplication feature so that if a mail list subscriber is on multiple email lists that are cc'd/bcc'd they only get the message one time?
Yes, it's desirable. However, the question is actually quite complex because a 'User' may have many 'Address' entries. Here, does "subscriber" mean 'User' or 'Address'? I can see it going both ways. Some users have many addresses, all except one are pure forwarding, and they only want to read the email once. Other users have separate addresses for separate roles, and they want to have that message for context in each role even if they have read it before.
Hashing this out means it will take us some time to get it into a release. (That's IMO, I defer to Abhilash as project leader and Mark as having more experience if their opinions differ.)
Of course we could implement "de-dup" with the subscriber = 'Address' interpretation immediately, which provides substantial relief for many users, and later add a User config option for "Also de-dup equivalent addresses" for some definition of "equivalence" (I can think of two implementations already, that's what I do, complexify things ;-).
Are you aware of solutions feature outside of Mailman3 core? Say filtering in postfix-mta? (might complicate tracking of dups in postfix)
I'm sure there are no such. It's much simpler to implement in Mailman core because you don't need to deal with transporting Mailman to filter and filter to MTA, and more reliable to implement in core because Mailman knows a lot more about both subscriptions and messages than you could deduce from the message itself. It's not impossible, of course, but I think it would be hard to implement well.
For "mailman core", could we filter in outbound send of mailman? Example - could the processing pipeline be modified to track/discard duplicate msgs?
I'm not sure what you mean by modifying the processing pipeline, but the basic idea is pretty clear. At some point the list name has to be expanded into a list of addresses. This is done by a specific handler in the pipeline, and the filtering will be done at that time. There are a number of possible implementations. We'd start by looking up all of each subscription's list affiliations when we look up the subscription configuration. In some cases we could create addressee lists for all the relevant mailing lists at that time, then send the message to the outgoing pipeline of each list to be decorated appropriately, but I'm not sure whether it's worth trying to do that. We'd also have to keep a record of lists of addresses (or Users) wanting de-duplication identified by Message-ID for some period of time in case the sender's MTA sent the message multiple times rather than providing multiple recipients in one transaction.
Steve