LWN: Comments on "A preview of HyperKitty's reimagined mailing list interface"

Trusting user-supplied data...

cjwatson — Sat, 13 Jan 2018 14:40:53 +0000

Looking at the code, it seems reasonably clear that HyperKitty will discard later duplicates.

A preview of HyperKitty's reimagined mailing list interface

cjwatson — Sat, 13 Jan 2018 14:29:47 +0000

I realise this is thread necromancy, but I thought I'd note that export-to-mbox was added in HyperKitty 1.0.3 (2015-11-15). It looks like you can filter by date range, thread ID, or message ID.

A preview of HyperKitty's reimagined mailing list interface

anselm — Thu, 04 Sep 2014 07:14:25 +0000

NNTP is not a complicated protocol at all. I remember writing a simple NNTP server for in-house use in the early 1990s, and it took me about a day or so (in Perl).

If you're looking for complicated protocols, try IMAP.

A preview of HyperKitty's reimagined mailing list interface

Cyberax — Thu, 04 Sep 2014 06:50:00 +0000

No. Just no.

NNTS's passed on! This protocol is no more! It has ceased to be! It's expired and gone to meet its maker! It's a stiff! Bereft of life, it rests in peace! If you hadn't nailed it to the forum it'd be pushing up the daisies! Its metabolic processes are now history! It's off the twig! It's kicked the bucket, it's shuffled off its mortal coil, run down the curtain and joined the bleeding choir invisible!! THIS IS AN EX-PROTOCOL!!

It's way overcomplicated and is designed for a completely different era. It doesn't provide archive retrieval services, for one thing. You either have to sync everything or you're screwed.

A preview of HyperKitty's reimagined mailing list interface

QNX — Thu, 04 Sep 2014 06:20:20 +0000

I'm glad I'm not the only one to show NNTP a little respect. I'd go a step further though. Gmane shouldn't have to exist, mailing lists for discussion shouldn't exist in the first place. NNTP is the proper protocol for many-to-many discourse, not SMTP.

A few years ago I started prototyping an NNTP backed threaded Web forum. I abandoned it for a serious lack of time. Content needs to be separated from presentation while providing a stable API for access to the backend store.

I still need to take a closer look at Discourse.

A preview of HyperKitty's reimagined mailing list interface

mylwn3 — Fri, 09 May 2014 20:05:25 +0000

An nntp service a'la gmane is what I want. It sounds like this is something that could be possibly written for in mailman 3. Until then, I'll still be happily using gmane. I've never met a web forum I've liked. They're all horrible.

A preview of HyperKitty's reimagined mailing list interface

nix — Tue, 06 May 2014 23:11:33 +0000

You forget that many people like to know which way the herd is going in order that they can follow. :)

(Of course I have to link to <https://xkcd.com/1013/> at this point.)

Board Interface

nix — Tue, 06 May 2014 23:09:36 +0000

Yes please! I've been using this setup for email for so many years that I'm periodically surprised when I realise that not everyone does it like this. (Actually I have a summary list at the top, a tree view in the middle -- though on the upper right like slrn would be fine too -- and the article filling the rest of the screen.)

Discourse

nix — Tue, 06 May 2014 23:07:30 +0000

I don't want 'download archive'. If this is going to be used for development lists, I want 'act as IMAP server dammit' so I can use the same mail-management tools that I use for every other development list I'm on. Don't inflict this stuff on those of us who don't spend our lives in web browsers...

A preview of HyperKitty's reimagined mailing list interface

duffy — Tue, 06 May 2014 13:35:32 +0000

PS here's an RFE I filed for looking into this:
https://fedorahosted.org/hyperkitty/ticket/68

Board Interface

duffy — Tue, 06 May 2014 01:36:48 +0000

I think this is a great idea! I've made an RFE ticket for it here:
https://fedorahosted.org/hyperkitty/ticket/67

A preview of HyperKitty's reimagined mailing list interface

duffy — Tue, 06 May 2014 01:31:06 +0000

s/interesting/provocative and you're right. :-/

A preview of HyperKitty's reimagined mailing list interface

duffy — Tue, 06 May 2014 01:25:16 +0000

The point behind having like/dislike in the system was as others have said - basically, to try to eliminate 'me too' or negative posts that only serve to voice disagreement without productive suggestions for improvement.

That being said, I think there may be some merit into the personal like/dislike system that Johann mentioned and the advogato system, so we could look into those and see if it'd be possible to switch mechanisms.

Trusting user-supplied data...

dlang — Mon, 05 May 2014 22:22:43 +0000

I don't know specific names, but given the horrific problems I've seen in this area, I'd bet that there are MUAs that do have predictable message IDs

worth attacking? that depends who uses them.

Trusting user-supplied data...

anguslees — Mon, 05 May 2014 22:19:20 +0000

... So if the archive discards later duplicates (rather than overwrites earlier entries), have we addressed this issue? (Are there muas with predictable message ids that are worth attacking in this way?)

A preview of HyperKitty's reimagined mailing list interface

Tjebbe — Mon, 05 May 2014 08:38:26 +0000

When asking about which one direction member is prettier, this may not be the most important feature.

But when asking, say, a technical question, there may be a number of wrong answers, a number of right ones that simply explain it badly, a number of unrelated answers, a number of rude ones, and a number of correct ones that happen to be well-written and generally more useful than all the others. Those are the ones you might want to have bubble up among all the others.

And the same for other types of discussions; there may be knee-jerk reactions, ad-hominems, offtopics, etc. In any busy discussion group, it helps if it is easy to see which ones are generally thought of as better-written/throught-out than the others.

Of course you don't want to hide them or move them to some bin where you never look, but +/- on comment definitely has its uses.

A preview of HyperKitty's reimagined mailing list interface

dlang — Sun, 04 May 2014 05:36:57 +0000

In terms of presenting a web view of (and access to) a mailing list, there are a couple other options to look at as well.

Nabble.com is a closed-source-but-free-to-use site that can act as a front-end for a mailing list, see http://postgresql.1045698.n5.nabble.com/PostgreSQL-f18437... as an example

FudForum can integrate with nntp, and so can mailman, so you can create a e-mail/nntp/web messaging system that allows people to use whichever posting and reading method they prefer. bar.baen.com is a registration-required example of this in action (forums for the Sci-Fi publisher Baen Books, registration is required to prevent any claims that content posted there counts as "first publication" for writers). This site has been running like this for a bit over a year now.

It will be interesting to see if Mailman can come up with another good option here. I've seen several other places facing the problems of fragmenting the user base and question-answering resources between web forums and mailing lists. Gaining more ways to integrate them together would be a very good thing.

A preview of HyperKitty's reimagined mailing list interface

BenHutchings — Sat, 03 May 2014 23:08:22 +0000

Even today, those mboxes are usually corrupted (stripped attachments, mangled email addresses).

Trusting user-supplied data...

rsidd — Sat, 03 May 2014 14:20:01 +0000

Being able to replace a message is indeed bad. I didn't read carefully enough to notice that, I guess. I assumed that either all messages would be shown, or, in searching by message-id, one (presumably the first) would be shown.

Trusting user-supplied data...

dskoll — Sat, 03 May 2014 13:52:43 +0000

The exploit is being able to replace the content of an archived message with your own content.

For example, let's say on a security mailing list, someone posts a critical patch for an important piece of software. And an attacker posts an alternate version of the patch that leaves a hole open. Anyone searching the list archive for the patch will get the bad patch instead of the good one.

Trusting user-supplied data...

NAR — Sat, 03 May 2014 13:37:15 +0000

Quite far fetched scenario, but
1, let's suppose there's a highly useful message on a mailing list (e.g. about enabling non-threaded view of messages in gmail). This message contains a link to "log in to gmail". It is so highly useful, that many people link to it and eventually Google will show it first for some search terms.
2, bad guy sends a message with the same Message-ID and same contents, except that "log in to gmail" link points to his server (phising(?) attack). This message replaces the original good message in the archives, so when new google searches provide the message, the users get the wrong link. They might get surprised that google asks for their password again, but if they type it, the bad guy gets their password...

Trusting user-supplied data...

rsidd — Sat, 03 May 2014 08:27:54 +0000

Yes, but what's the exploit here?

like/dislikes

jwakely — Fri, 02 May 2014 18:00:46 +0000

Advogato's diary ratings got that right, based on its trust metric: http://advogato.org/trust-metric.html

Discourse

fandingo — Fri, 02 May 2014 17:43:33 +0000

HyperKitty (and Reddit, which was an example from the article) both have RESTful APIs that can be used to download any content that you may want to archive locally. "Rich format" as a barrier to archival is a false complaint.

Trusting user-supplied data...

hmh — Fri, 02 May 2014 14:47:06 +0000

It is not only utterly easy to cause message-id colisions on purpose, it will also happen quite often due to defects in very commonly used email user agents.

Passwords

mathstuf — Fri, 02 May 2014 14:35:40 +0000

Agreed. It's a mailing list and not a bank account. We don't need to go from "plaintext storage we email you every month" to "PGP-based web of trust" for it. Now, for the banks…

Trusting user-supplied data...

ms-tg — Fri, 02 May 2014 14:31:32 +0000

> Anyway, the point is... Message-ID: is not a good choice for a
> unique message identifier. It's under the control of potentially
> malicious clients.

I am assuming that there is an implied exploit here:
1. Send a bunch of emails with duplicate ID's but different content
2. ??

Am I correctly understanding what this comment, and others, are saying?

like/dislikes

johannbg — Fri, 02 May 2014 14:18:48 +0000

The like/dislilke should be implemented based on personal preference not controlled by majority...

A preview of HyperKitty's reimagined mailing list interface

mattdm — Fri, 02 May 2014 12:51:33 +0000

> Interesting for whom? Do we have a useful notion of "average taste"?

For the people who are part of the project for which the mailing list exists.

"Average"? I don't think that applies. A more interesting question is: Do we have a useful notion of the _collective_ taste of the contributors to a project? This is specifically a way to get a sense of that.

> Moreover, if it's really that interesting, there must be replies.

This.... seems like a comment from someone who doesn't use mailing lists very much. It's true that most interesting comments will get replies, but the problem is that so will very many others.

Passwords

dskoll — Fri, 02 May 2014 11:24:19 +0000

That's over-engineering it. mathstuf's suggestion is probably fine: you just have "email me a login link" which times out in an hour or two and have no passwords whatsoever.

A preview of HyperKitty's reimagined mailing list interface

deepfire — Fri, 02 May 2014 09:52:20 +0000

Moreover, if it's really that interesting, there must be replies.

A preview of HyperKitty's reimagined mailing list interface

deepfire — Fri, 02 May 2014 09:51:01 +0000

Interesting for whom? Do we have a useful notion of "average taste"?

A preview of HyperKitty's reimagined mailing list interface

ovitters — Fri, 02 May 2014 08:51:55 +0000

Looking forward to the new mailman. The current version is pretty terrible usability wise. Meaning that it was good at the time, but really showing its age. I've slightly followed version 3 development and like the idea that a user exists across mailing lists. HyperKitty seems really nice. Hopefully enough people try out the beta release, rather not do that.

Development has been awfully slow though, which is rather unfortunate.

Passwords

clint — Thu, 01 May 2014 21:52:10 +0000

Let's say I have a shell account somewhere where I can run monkeysphere but there is no site-wide Monkeysphere policy or activity. Using whatever alternate methods I currently have to authenticate, I can log in and configure any set of OpenPGP keys to be trusted identity certifiers, and any set of OpenPGP userids to represent authorized users of my shell account.

You can implement the same concepts in anything that uses OpenPGP authentication, without using any Monkeysphere software: in effect, a per-user pair of (trusted keyring and a set of authorized user IDs). Everything is localized solely to you unless you choose it not to be.

Passwords

mathstuf — Thu, 01 May 2014 21:24:42 +0000

Could you give more details? That sounds like giving the user the lock and key to something without knowing what "monkeysphere" is.

Passwords

clint — Thu, 01 May 2014 20:35:23 +0000

You could have per-user sets of OpenPGP trust roots, monkeysphere-style.

A preview of HyperKitty's reimagined mailing list interface

mtaht — Thu, 01 May 2014 18:15:57 +0000

did they finally add pgp support? been out of tree for years....

A preview of HyperKitty's reimagined mailing list interface

Cyberax — Thu, 01 May 2014 17:41:03 +0000

Like, maybe, highlighting an interesting post in a lengthy discussion?

A preview of HyperKitty's reimagined mailing list interface

viro — Thu, 01 May 2014 17:26:16 +0000

Pardon my bluntness, what is the value of information that $N wankers with nothing to contribute had found $POSTING gratifying? If somebody can't be arsed to back their opinion by evidence, or at least by some attempt at arguments, that opinion is worthless by definition. AFAICS, the only possible use for such information is data mining for some kind of spam...

A preview of HyperKitty's reimagined mailing list interface

smurf — Thu, 01 May 2014 14:03:20 +0000

Quite frankly, as long as Mailman *finally* understands non-ASCII characters in greeting messages and whatnot, I will be perfectly happy.

Everything else is nice-to-have.

NB: This is probably the longest period between alpha and beta release of a single program ever. 3.0.0a1 was released on 2008-04-08, according to Launchpad. Let's hope that the Beta period is a bit shorter than that.