[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mailman-developers
Subject:    Re: [Mailman-Developers] [Bug 985149] [NEW] Add List-Post value to permalink hash input
From:       Barry Warsaw <barry () list ! org>
Date:       2012-04-23 23:38:41
Message-ID: 20120423193841.3d0517e0 () resist ! wooz ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

>On Sat, Apr 21, 2012 at 1:22 AM, Barry Warsaw <barry@list.org> wrote:
>
>> I think the hash value should be opaque. =C2=A0Jeff can perhaps elaborat=
e 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 val=
ue.
>> IOW, if you cross-post a message with Message-ID: <foo> to one@example.o=
rg and
>> two@example.com, you'd get two different messages forwarded to the archi=
ves,
>> and they would have different Permalink: hash values. =C2=A0Before 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@example.org or
two@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 identi=
cal
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 sto=
re
the whole message contents.

-Barry


["signature.asc" (application/pgp-signature)]

_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
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/mailman-developers%40progressive-comp.com


Security Policy: http://wiki.list.org/x/QIA9



[prev in list] [next in list] [prev in thread] [next in thread]