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

Issue #719 open
Ian Hinder created an issue

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.

Keyword:

Comments (18)

  1. Ian Hinder reporter
    • removed comment

    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.

  2. Frank Löffler
    • changed status to open
    • removed 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.

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

    Attached is a more substantial attempt. comment:5🎫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.

  4. Roland Haas
    • removed comment

    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.

  5. Frank Löffler
    • removed comment

    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.

  6. Frank Löffler
    • removed comment

    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

  7. Roland Haas
    • removed comment

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

  8. Frank Löffler
    • removed comment

    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.

  9. anonymous
    • removed comment

    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.

  10. Log in to comment