[Mailman-Developers] [Bug 985149] [NEW] Add List-Post value to permalink hash input

[Barry Warsaw]

On Apr 21, 2012, at 10:19 AM, Stephen J. Turnbull wrote:

>On Sat, Apr 21, 2012 at 1:22 AM, Barry Warsaw <barry at list.org> 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 one at example.org and
>> two at example.com, 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 one at example.org or
two at example.org?  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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120423/f51104be/attachment-0001.pgp>