Included clickable link to archived posting in users list emails

Create issue
Issue #1529 closed
Roland Haas created an issue

I find myself often wanting to cite an email on the user's list in eg track tickets and usually want to provide a url to the email in the mailing list archive for this. Right now this requires me to manually navigate to the mailman archive ( click on the relevant year and month and find the posting in question based on its subject line and author.

It would be very nice is the emails were tagged with a unique identifier that could then be used to retrieve it from the mailing list archive (and if this tag showed up eg in the footer that already contains the url of the listinfo page). One such identifier that may be available would be the message number (eg 003400 for I have no idea how hard providing this would be though.


Comments (7)

  1. Frank Löffler
    • changed status to resolved
    • removed comment

    I read about this being often requested, but not really possible. It's a chicken and egg problem. Before the message is delivered into the archive such a number doesn't exist yet, so it cannot be included in the message itself. But once it is in the archive it cannot be changed anymore. In principle this could probably be addressed by a change to mailman, but unless this is done upstream I don't see a way we could do this.

  2. Erik Schnetter
    • removed comment

    Each email has an id, which is typically a long string of letters and numbers. This id can be turned into a url by mailman, at least in principle. Mailman could also add this url to the bottom of each email. Or mailman can generate such an id itself when it receives an email and decides to actually send it to the list. The url could even be a search-type url (akin to

  3. Roland Haas reporter
    • changed status to open
    • removed comment

    Alright. One can use the message-id when making a one-line hack to mailman. The attached patch is for /usr/lib/mailman/Mailman/Archiver/ which is the tool actually generating the archives. It replaces the sequence number of the posting (which is what is usually used for the URL) by the first part of the message id. Eg for it would generate which is almost unique (the message ID is created by the sender it seems so two sender could in principle create the same ID).

    If one does not want to hack a file installed by the package manager (or if you are not root) but can at least modify /etc/mailman/ then one can use the entry PUBLIC_EXTERNAL_ARCHIVER (see /usr/lib/mailman/Mailman/ to replace the default archiver with a copy of lines 210--216 of /usr/lib/mailman/Mailman/ that uses the modified .

    To get the message id to show up in the email text (rather than just the email header, which requires inspecting the message source in one's email client), one can modify and add a new field "msg_id" to the allowed values in mailing list (Non-digest options, the web-gui complain but things work anyway).

    Maybe a student can be found who is willing to turn these into a "nice" method. What I described works in a test setup inside of a virtual machine but I have no idea what kind of access level we have to the machine that runs the ET mailing list.

  4. Frank Löffler
    • removed comment

    Using a message id is interesting, but has the problem that while message ids are generated by most email clients, they are optional. Emails without id are perfectly valid, and any mailman modification would have to take that into account. That's probably only a minor problem.

    What can be more of a problem is that a message id is user-generated, and this way would end up in an URL. We would have to make very sure this is properly escaped. I don't want to see URLs like valid_stuff@my.evil.domain.overseas on the ET archive - or similar. Also this might be not such big of a problem as the lists currently only allow known users to post, and others have to go through a filter (me).

    This feature seems to be possible in Mailman 3 - with the only problem being that this isn't released yet (in it's third beta). Development is visible there, but seems to be slow.

  5. Roland Haas reporter
    • changed status to resolved
    • removed comment

    Actually this ticket is an almost exact duplicate of #719 which is 22 months old. Apparently in this time mailman 3 has not been forthcoming. I suggest we do not wait for mailman 3 and instead try and run our own scheme. Closing this bug and moving the patches to #719.

  6. Log in to comment