- changed status to resolved
- removed comment
Included clickable link to archived posting in users list emails
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 (http://lists.einsteintoolkit.org/pipermail/users/) 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 http://lists.einsteintoolkit.org/pipermail/users/2014-January/003400.html). I have no idea how hard providing this would be though.
Keyword:
Comments (6)
-
-
- 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 http://mailman.cactuscode.org/search?id=...).
-
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/HyperArch.py 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 http://lists.einsteintoolkit.org/pipermail/users/2014-January/003400.html it would generate http://lists.einsteintoolkit.org/pipermail/users/2014-January/20140106182143.GH6244.html 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/mm_cfg.py then one can use the entry PUBLIC_EXTERNAL_ARCHIVER (see /usr/lib/mailman/Mailman/Defaults.py) to replace the default archiver with a copy of lines 210--216 of /usr/lib/mailman/Mailman/Defaults.py that uses the modified HyperArch.py .
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 Decorate.py 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.
-
reporter - changed status to open
- removed comment
-
- 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.
-
reporter - changed status to resolved
- removed comment
- Log in to 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.