[Einstein Toolkit] #719: Mailing lists could have a link to the archived version of the message
#719: Mailing lists could have a link to the archived version of the message -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- It would be useful for the footer of a mailing list posting to contain a URL to the archived version of the message so that it is easy to point people to the message in an email. This would apply to both the Cactus and the ET lists.
It appears that this is not straightforward in MailMan 2, but is expected in version 3: http://mail.python.org/pipermail/mailman- users/2011-October/072378.html.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: Other | Version: Resolution: wontfix | Keywords: --------------------------+------------------------------------------------- Changes (by knarf):
* status: new => closed * resolution: => wontfix
Comment:
As long as Mailman 3 isn't out - which is not likely happening soon -> wontfix.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: Other | Version: Resolution: wontfix | Keywords: --------------------------+-------------------------------------------------
Comment (by hinder):
I don't see the value in closing the ticket. It just means we will forget about the issue. This is a desired feature which we would like to implement in the future, when it becomes feasible to do so. Having open tickets which we cannot address immediately is not a problem.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: reopened Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by knarf):
* status: closed => reopened * resolution: wontfix =>
Comment:
My intention was to prevent trac being filled with wish-list items that might only be resolved on a long-term basis, if at all.
Given that nobody really wants (or can) implement this in Mailman 2 (since at the time of mailing the location within the archive isn't known yet, and changing that would require a lot of changes within Mailman), and also Mailman 3 isn't likely to be released soon (meaning within the next two years) the only fate this ticket would have is stagnation.
On the other side I can understand also your argument. Reopening.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by rhaas):
* status: reopened => review
Comment:
Attached is a more substantial attempt. comment:5:ticket:1529 raised some issues wrt to security and unavailability of message-id. I have amended the patches to fall back to sequence number if message-id is missing (tough none of the emails in the ET mailing list are lacking a message-id right now). I have also tried to make the constructed archive path "safe". I am not concerned with funny urls appearing in the emails, since if I'd want to stick a strange URL in the mailing list, I could just send an message to the list. The bigger issue was that the previous patch would have blindly used the (user supplied) message ID to create the path for the file that archives the message. Since the archiver can overwrite web- pages this would have allowed a user to change the website content.
The attached patch tries to provide an archive_url variable that can be used in the footer. Constructing the URL cannot be done nicely since it relies on internal knowledge of the archiver (HyperArch) that is not directly accessible when constructing the footer. So I have put in code (stolen from the "correct" place) that handles our usage case. One could probably make this work more nicely, however it seems not worth the effort.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
During the phone call today, we decided to include more than just [A-Za-z0-9-] in the message id and instead use the full message-id in a sanitized form. Apparently message-id's can contain any printable characters other than [<>@]. See http://www.freesoft.org/CIE/RFC/850/10.htm so we'd likely want to escape the @ sign to _AT_ and have to escape the "/" to _SLASH_ and then should likely escape the underscore itself to _UNDERSCORE_ to avoid conflicts between underscores due to escaping and those originally present in the messag ID.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
I don't think we need to go to something like _UNDERSCORE_. Even if we map multiple characters like @_/ all to _, the resulting message ID should be fine. We don't ever need to convert it back. Replacing the @ with something like _AT_ has just the advantage of retaining some of the readability - if that is somehow important.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
Any chance on possibly implementing this on the ET servers?
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by hinder):
Frank, is this OK to implement?
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by anonymous):
Yes, it is. Assuming I find some time. I'll keep the ticket open.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by knarf):
* owner: => knarf * status: review => assigned
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
Decorate.py:
It gets message-id, and set's it to 'n/a' if not available, but then cuts everything after a "@" by using [1:msgid.find("@")]. This is wrong in case there is no "@" in the string, which in particular would be the case for the earlier caught 'n/a'. Is this first patch supposed to be superseeded by the second?
HyperArch.py:
Is the first patch supposed to be superseeded by the second?
The second patch: It seems to still use only the limited set of ([a-zA-Z0-9-]+ for parsing, and it still falls back to the real message ID in case it does not fall into that - which still opens a security hole. The set should be wider (see comment:5) and the archived_url has to be sanitized, with the message ID being not trusted.
Where is {{{d['archive_url']}}} finally used? It is set by Decorate.py.2.patch
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
This has been a while. Alright, let me see. You should only look at the .2.patch files. Ie. Decorate.py.2.patch and HyperArch.py.2.patch. The other two files are older versions (and I cannot remove attachments from a ticket, so once the upload system adds a new version, I cannot remove the old one).
Decorate.py:: This patch is superseded by Decoreate.py.2.patch, which no longer assumes a {{{@}}} to be present and instead uses only {{{[A-Za-z0-9-]}}} which is actually too restrictive and will often fall back on just the serial number. Instead we should use this: {{{ def get_unique_id(self): """return a unique ID consisting of only path-safe characters constructed from either the Message-ID or the sequence number""" retval = "%06i" % (self.sequence,) try: if self.msgid and self.msgid != 'n/a': retval = re.sub('/', '_', self.msgid) except AttributeError: pass return retval }}} which replaces all "/" in the message id by "_" to make the ID usable as a file name.
HyperArch.py (really HyperArch.py.2.patch):: As for {{{d['archive_url']}}}: mailman's {{{decorate}}} function (defined in {{{Decorate.py}}}) will add anything that the administrator specifies in mailman's web interface (see https://www.gnu.org/software/mailman /mailman-admin/node18.html). This is the proper way to integrate this information into mailman rather than just hard-code it into the python code. It's also easier to code up :-).
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
Mailman 3.0, which offers this feature natively, has been released: https://mail.python.org/pipermail/mailman-announce/2015-April/000210.html is the announcement email, http://www.gnu.org/software/mailman/ is the mailman website.
It would be very nice if we could use this very soon.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
While it was released, it doesn't sound like the developers don't quite suggest updating existing installations just yet. From http://wiki.list.org/Mailman3:
While it is possible to upgrade existing Mailman 2.1 lists to run on Mailman 3, we are not yet officially sanctioning it. The plan is to officially support upgrades with Mailman 3.1, but for now, feel free to experiment with upgrading and let us know how it goes.
This doesn't mean we couldn't try, but it looks like we would have to find a mailman enthusiast with a lot of time.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
Mailman 3.1 has been released which is the stable version and the one to be used to upgrade from mailman 2.1. See https://mail.python.org/pipermail /mailman-announce/2017-May/000228.html for the announcement.
With this version out there is no reason for us to avoid upgrading anymore and we should do so after the release to get eg links to the archived versions of emails in the mails themselves.
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------------------------------- Reporter: hinder | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
Ping. Now mailman 3.1.1 is out.
http://mailman.rtfd.io/en/release-3.1/src/mailman/docs/NEWS.html
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------- Reporter: Ian Hinder | Owner: Roland Haas Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+------------------------- Changes (by Frank Löffler):
* owner: Frank Löffler => Roland Haas
#719: Mailing lists could have a link to the archived version of the message --------------------------+------------------------- Reporter: Ian Hinder | Owner: Roland Haas Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Other | Version: Resolution: | Keywords: --------------------------+-------------------------
Comment (by anonymous):
Uhm, the best solution would be to install mailman 3.1 which is the stable release of mailman 3 which does officially support this thing rather than using my somewhat hackish method.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit