Modify

Opened 7 years ago

Last modified 6 months ago

#719 assigned enhancement

Mailing lists could have a link to the archived version of the message

Reported by: Ian Hinder Owned by: Roland Haas
Priority: minor Milestone:
Component: Other Version:
Keywords: Cc:

Description

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.

Attachments (4)

Decorate.py.patch (490 bytes) - added by Roland Haas 5 years ago.
HyperArch.py.patch (434 bytes) - added by Roland Haas 5 years ago.
Decorate.py.2.patch (2.2 KB) - added by Roland Haas 5 years ago.
HyperArch.py.2.patch (1.0 KB) - added by Roland Haas 5 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 7 years ago by Frank Löffler

Resolution: wontfix
Status: newclosed

As long as Mailman 3 isn't out - which is not likely happening soon -> wontfix.

comment:2 Changed 7 years ago by Ian 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.

comment:3 Changed 7 years ago by Frank Löffler

Resolution: wontfix
Status: closedreopened

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.

Changed 5 years ago by Roland Haas

Attachment: Decorate.py.patch added

Changed 5 years ago by Roland Haas

Attachment: HyperArch.py.patch added

Changed 5 years ago by Roland Haas

Attachment: Decorate.py.2.patch added

Changed 5 years ago by Roland Haas

Attachment: HyperArch.py.2.patch added

comment:4 Changed 5 years ago by Roland Haas

Status: reopenedreview

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.

comment:5 Changed 5 years ago by Roland Haas

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.

comment:6 Changed 5 years ago by Frank Löffler

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.

comment:7 Changed 5 years ago by Roland Haas

Any chance on possibly implementing this on the ET servers?

comment:8 Changed 4 years ago by Ian Hinder

Frank, is this OK to implement?

comment:9 Changed 4 years ago by anonymous

Yes, it is. Assuming I find some time. I'll keep the ticket open.

comment:10 Changed 4 years ago by Frank Löffler

Owner: set to Frank Löffler
Status: reviewassigned

comment:11 Changed 4 years ago by Frank Löffler

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

comment:12 Changed 4 years ago by Roland Haas

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 :-).

comment:13 Changed 4 years ago by Roland Haas

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.

comment:14 Changed 4 years ago by Frank Löffler

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.

comment:15 Changed 18 months ago by Roland Haas

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.

comment:17 Changed 6 months ago by Frank Löffler

Owner: changed from Frank Löffler to Roland Haas

comment:18 Changed 6 months ago 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain Roland Haas.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Roland Haas to the specified user.
The owner will be changed from Roland Haas to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.