On Apr 21, 2012, at 10:19 AM, Stephen J. Turnbull wrote: >On Sat, Apr 21, 2012 at 1:22 AM, Barry Warsaw <[email protected]> wrote: > >> I think the hash value should be opaque. Jeff can perhaps elaborate his >> use-case but I don't think the List-ID needs to be (or frankly *should* be) >> extractable from the hash, but instead just needs to inform the hash value. >> IOW, if you cross-post a message with Message-ID: <foo> to [email protected] >> and >> [email protected], you'd get two different messages forwarded to the archives, >> and they would have different Permalink: hash values. Before this proposal, >> they'd have the same value. > >Which is a FAQ: how do I avoid getting two copies of the same message >from multiple lists I subscribe to? If Mailman is maintaining a list >of messages received, with full personalization this FAQ now has an >acceptable answer. If Mailman distinguishes the same message posted >to different lists in an opaque way, the answer is "we're sorry, >Mailman cannot do that by design." > >Or do you see a way to do this that I don't?
That's actually a separate question from what gets transmitted to the archiver. Mailman *could* de-dupe the rosters for any cross-posted messages to mailing lists that it manages, but it would have to know how to prefer one mailing list copy over another. E.g. do you get the footers from [email protected] or [email protected]? mm3 current does not do this de-duping. Regardless of what it delivers to actually list recipients, what would it do when transmitting the message to the archiver? There are a number of things it could do, but right now, the archiver would get two messages with identical Message-IDs. In the implementation of IArchive for any particular archiver, some persistent state could be managed and de-duping could happen there. I think it's not worth doing it there, but it wouldn't be infeasible. >> Of course, the List-ID itself should be preserved in the message that the >> archiver gets, so an archiver could still discriminate on that. > >Not good enough, because the de-dupe db will store hashes AIUI. If >the de-dupe db stores Message-IDs, then you have enough information. I think the core's db will have to store Message-IDs. It may also store the hashes, or other information, but as we've determined, it won't need to store the whole message contents. -Barry
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
