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

[Barry Warsaw]

On Apr 22, 2012, at 03:31 PM, Jeff Breidenbach wrote:

>I find List-Id annoying because I like the world to be simple and easy to
>understand. People who know nothing about RFCs natually consider the
>posting address to be the canonical name of a mailing list. We should be
>embracing that.

In theory, I agree, which is why you'll see the posting address used as the
primary key into the mailinglist table in the database.  You'll almost always
see that in the To: header, although some situations might cause mismatches,
e.g. acceptable aliases.  According to the language in RFC 2369, this also
(only!) may show up in the List-Post header for the from-list copy of the
message, but you might find the List-Post has nothing useful, e.g. "NO" (with
some random goo of trailing comment).  List-ID will always be included in the
from-list copy.

>Instead, RFC2369 introduces this entire alternate namespace with List-Id,
>competing for attention, with its own weird rules like the domain-control one
>quoted earlier in its thread. All this confusion, and the main problem it
>tried to address isn't very important. Is it really such a disaster for a
>list to be considered different if it hops to a new domain? I don't think so,
>or there would be a lot more clamoring for editable List-Id in
>mailman. Archival services certainly don't need it. It smells like design by
>committee where everyone's pet feature for a rare use case gets added in,
>without appreciating the benefits of small and simple and
>less-stuff-is-better.
>
>Regarding hashes, the whole point of a archival hash is to make a shorter,
>human friendly URL. This is not very to implement; one can take the SHA-1
>and truncate it. If we aren't worried about length then Message-Id is a
>perfectly usable identifier.

Well, Message-ID also fails the "human friendly" part, e.g. from your message:

Message-ID:
 <CAHjiUboZzYAE1dgApzfFNMqv_X+X6xA9E1bOc3F+mQ3qcTeeeQ at mail.gmail.com>

My fingers already hurt typing that into my spell-correcting smartphone. :)

FWIW, Base 32 was deliberately chosen because it's case insensitive, and
allows for optional mapping of commonly mistaken substitutions (e.g. zero for
oh, and one for eye or el).  IOW, it's much more forgiving of the human part
of the process.

>Certainly no need for a triumverate of short hash, long hash, and
>message-id. Less is better.

Agreed.  Is 32 bytes too long?  Is 4 bytes too short?  What's an acceptable
trade-off between collision likelihood and human convenience?

-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/43bc223f/attachment.pgp>