29041 - Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369

Status: RESOLVED FIXED

(MailNews Core :: Composition, enhancement, P3)

Description

[John G. Myers]

Mozilla should support RFC 2369, a Proposed Standard.

Technical Summary
 
 This document describes one way to alleviate the frustration of
 trying to get on or off a mailing list, by providing a fixed place
 in the message header where information about the mailing list, such
 as how to unsubscribe, can be put in the form of an URL.

Comment 1

[Phil Peterson]

Neat idea. -> helpwanted

Comment 2

[Boris Zbarsky [:bzbarsky]]

*** Bug 87299 has been marked as a duplicate of this bug. ***

Comment 3

[David Hallowell]

*** Bug 93253 has been marked as a duplicate of this bug. ***

Comment 4

[David Hallowell]

A possible useful link from bug 93253: http://www.nisto.com/listspec/

Also see bug 93253 for a description of how pine handles this.

Nominating for Mozilla 1.1 as I think there's more important stuff needed
implemented/fixed before this feature but it's definitely a useful enhancement
and should be supported.

Comment 5

[Daniel Mario Vega (Restore MNG Support --> #18574)]

In the following URL there is a brief explanation how "Pegasus Mail" handles
this feature:

http://www2.angen.net/~pegasus/secrets.html#maillist

Comment 6

[m_mozilla]

note that this feature should never actually *send* messages when using a
mailto: URL, but rather just create them. In particular, users should be able to
adjust their personality before sending. They may not be subscribed under their
default personality and attempting to unsubscribe their default personality
would fail.

A future enhancment might try to pre-select the appropriate personality, and/or
allow the user to use an arbitrary From: address, or provide a list of From:
addresses from the headers (including greped out of Received: headers) in the
message.

-matt

Comment 7

[mozbug1]

Isn't implementing this as simple as adding those headers to the list of headers
displayed (currently Subject, From, Date, To, CC)?

Comment 8

[Jungshik Shin]

> Isn't implementing this as simple as adding those headers to the list of 
> headers displayed (currently Subject, From, Date, To, CC)?

  That might be the simplest approach, but I'm afraid that's not the best
possible. Rather, I'd treat 'mailing list managment info' similar to the
way attachment is treated. That is, bring up a small icon indicating that
there's 'list management info'. When it's clicked on, a pop-up menu
appears with the list of things (subscribe, unsubscribe, help request,
digest,etc). This is similar to what Pine does in text mode. 

Comment 9

[R.K.Aa.]

*** Bug 159056 has been marked as a duplicate of this bug. ***

Comment 10

[Roger B.A. Klorese]

IMP also has a nice implementation: in addition to brief and full headers, it
has a "show list headers" mode.  The best part of their implementation is that
"reply" and "reply to all" are joined by a "reply to list" button.

Comment 11

[Alan]

*** Bug 167994 has been marked as a duplicate of this bug. ***

Comment 12

[lloyd]

A feature that might make Mozilla a favorite in certain circles - 

An option to alert the user when about to send a message to a mailing list.

It takes only one embarrassing message mistakenly sent to a list instead of an
individual to make this a killer feature  :-)

Comment 13

[James Ross]

Does this bug cover all the "List manegement" headers, or just the unsubscribe
one? (description implies just the unsubscribe one, where as there's a
collection of other list-related headers).

Comment 14

[Roger B.A. Klorese]

I would hope all would be supported, for parity (at least) with other MUAs.

Comment 15

[Nowhere man]

Why have some bugs that have a more global view of the probelm been marked as
duplicates ? It's not only about un subscription, but all RFC 2369 headers
should be implemented...

I think bug 159056 should be reopened and bug 29041 marked duplicate of it, or
the title of bug 29041 should be changed.

Comment 16

[Toralf Lund]

I've always wanted this, too... I think the most useful feature would be a 
"followup to list" button, which would be like "Reply", only send to address
given in the "List-Post" header. But actually, maybe this address might be used
even for normal  "Reply". The point is that n 9 out of 10 cases when you "reply"
to a mailing list message, you want your comments to go to the list, not the
person who sent the original message. 

Comment 17

[Egon Face]

More information here:
http://forums.mozillazine.org/viewtopic.php?t=21703&highlight=

Comment 18

[Zak Kipling]

bug 45715 specifically refers to the "reply to list" feature

Comment 19

[Yves Lambert]

This block 45715. If really someone found that it depends on it they are dupe
(despite of Zak Kipling's comment #18

Comment 20

[Olivier Salaun]

(In reply to comment #13)
> Does this bug cover all the "List manegement" headers, or just the unsubscribe
> one? (description implies just the unsubscribe one, where as there's a
> collection of other list-related headers).

Handling the 'List-unsubscribe' is the most important feature because list
members have lots of difficulties to unsubscribe. It would also be a good idea
to exploit the "List-archive" link that is supposed to point to the list web
archives ; it is always hard for a list member to determine where are list
archives located. It would also be a good idea to point to the list owner, which
address is difficult to guess. Linking to the list page is also of interest,
using List-help. On the other hand, I don't think you have much to do with
List-post, List-post.

List managers has been implementing these header fields for a long time and it
is not used because they rely on MUAs and major MUAs don't implement these
usefull features. But it's never too late...

Comment 21

[Shriramana Sharma]

Please, let us see more work on this. Especially on the Reply-To-List feature.

Comment 22

[Toralf Lund]

There has been a lot of activity lately over at bug 45715. The material
submitted includes *some* code at least, and the rest might perhaps be called
actual design work...

Comment 23

[Wolfgang Rosenauer [:wolfiR]]

basic support is available as extension:
https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&category=Message%20Reading&numpg=10&id=576

Comment 24

[Roger B.A. Klorese]

Yes, it's available as an extension.

But:
- from a practical perspective, the lag between Thunderbird updates (and test releases) and extension updates is problematic
- more importantly, it's time this functionality was considered to be a core capability of mail management

Comment 25

[Wayne Mery (:wsmwk)]

bug 45715 has a patch - requires enigmail or meheny

Comment 26

[Reed Hedges]

I vote for this bug (though isn't it a "mail viewing" feature, not "composition"?).

In addition to the headers described in RFC 2369, many mailing lists also put the name of the mailing list in List-Id, which might be helpful in labels in the UI. (E.g. "Unsubscribe from <someMailingList>", "<SomeMailingList> Archives", etc.)

"Unsubscribe" is an action, so it should be displayed as a button. Archives URL (presumably usually http) and addresses like owner/admin, help, etc. are hyperlinks and should be displayed as such, either in the headers or elsewhere.
 
One important requirement in my opinion is to have an "Unsubscribe from this mailing list" toolbar button appear right next to the "Mark as Junk" button (if the headers are in the selected message), as a clearly visible alternative. (Then unaware users won't  mistakenly mark unwanted messages as spam).  This could be in addition to a button near the message headers if you want.

Thanks for considering this really useful feature!

Comment 27

[Matthew T (active 1999-2002)]

Spammers used to offer in-line "unsubscribe" links that did nothing except confirm to them that your address was worth spamming. They stopped doing this when (I assume) the words "unsubscribe", "remove" etc started slightly indicating spam (outweighed by ham indicators in real mailing lists, but not in spam). If RFC 2369 headers became widely supported, the same thing would happen: for a year or so, spammers would use them more than anyone else. So any implementation should have a UI that discourages use by spam recipients.

Comment 28

[Reed Hedges]

That's a good point, Matthew.  Perhaps we need to include in the UI itself any key pieces of information provided by the message that will help the user decide whether this was a legitimate mailing list they signed up for, or spam.  This includes the domain name from Sender (which usually ought to be something recognizable as the site of a real organization sending the list, not something arbitrary or strange looking), the name of the list,  etc.

We could also check to see how much info the message provides, and whether it makes sense.  E.g. only display the buttons if all headers, -Unsubscribe, -Subscribe, -Archives, -Help, etc. are all given and have different values (not just the same phony url).

Comment 30

[Christian Weiske]

I made two extensions dealing with mailing lists:
mailinglistheaders and replyToList
both can be found at http://cweiske.de/misc_extensions.htm

Comment 32

[Christian Schmidt]

(In reply to comment #27)
> So any implementation should have a UI that discourages use by spam recipients.
When the "Load Images" button has been pressed on an HTML message with remote images, following an unsubscribe link does not expose the user to additional risk of being tracked by spammers, i.e. Thunderbird can redirect the user to the specified URL without further warning.

Comment 36

[monperrus]

Would love to have this also.

Comment 38

[Andrei Hajdukewycz [:sancus]]

This is obviously backlog for now.

Comment 39

[Anthony Howe]

(In reply to Andrei Hajdukewycz [:sancus] from comment #38)

This is obviously backlog for now.

Frack annoy a comment. I wanted this long ago when Reply-to-List support came about and all you can say is "Backlog"!??!. Frick'n'L. If after 23 years you can't deal with something based on simple X- headers in an RFC then just mark it "Won't Do". 23 YEARS in queue. You just wait for requesters to die from old age?

And don't give me that "if you want it fixed, contribute to open source" line. I code for living and have supplied lots of open source. You can't be every where.

Comment 40

[monperrus]

For the record two plugins offer this feature:
https://addons.thunderbird.net/en-us/thunderbird/addon/unsub/
https://github.com/inxmailgmbh/tb-listunsubscribe

It would be great to have this by default.

Comment 42

[Magnus Melin [:mkmelin]]

Also https://datatracker.ietf.org/doc/html/rfc8058

Comment 43

[Jesse Thompson]

For the record two plugins offer this feature:
https://addons.thunderbird.net/en-us/thunderbird/addon/unsub/
https://github.com/inxmailgmbh/tb-listunsubscribe

Can manifest v4 extensions get permission to make POST requests to arbitrary URLs without CORS? It looks like this extension is broken because of that (based on my limited knowledge of extension development). Gmail and Yahoo are moving away from mailto 8058 unsubscribe, so if TB extensions are limited from making HTTP requests, then the requests need to come from TB core.

Comment 44

[Jesse Thompson]

If TB were to offer an 8058 unsubscribe API which causes a POST to the URL in the List-Unsubscribe header

8.  Examples

8.1.  Simple

   Header in Email

   List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click

   Resulting POST request

   POST /unsubscribe/opaquepart HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 26

   List-Unsubscribe=One-Click

With this simple API, the heavy work of UX can be handled by an extension developer.

Comment 45

[Magnus Melin [:mkmelin]]

RFC 8058 will have to be for another bug. It depends on DKIM which we don't support yet.

Comment 46

[Magnus Melin [:mkmelin]]

Attachment: Bug 29041 - Part 1: Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369. r=freaktechnik

This makes Thunderbird understand the RFC 2369 headers, and output them a functional.
Makes the headers useful when they are shown (through pref, and for All Headers) mode.

Comment 47

[Magnus Melin [:mkmelin]]

Attachment: Bug 29041 - Part 2: Use List-ID with context menu for list management. r=#thunderbird-front-end-reviewers

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/8fb8d48d0666
Part 1: Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369. r=freaktechnik

Comment 49

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/c10fd4598917
Part 2: Use List-ID with context menu for list management. r=aleca

Comment 50

[Magnus Melin [:mkmelin]]

Attachment: Bug 29041 - Fix bad interaction of mailnews.headers.extraExpandedHeaders settings and known headers. r=#thunderbird-reviewers

In case mailnews.headers.extraExpandedHeaders contains a header we "know about" and have
already defined behavior for, use the preferred behavior.
E.g. set List-Archive into the pref - without this fix it shows as a plain filed, not as a link.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a6e7c670f689
Fix bad interaction of mailnews.headers.extraExpandedHeaders settings and known headers. r=aleca

Comment 52

[Magnus Melin [:mkmelin]]

Attachment: Bug 29041 - Fake a List-Id when unsubscription is possible but no List-Id is set. r=#thunderbird-reviewers

Some newsletter type emails have List-Unsubscribe but don't set a List-Id.
For consistency, fake the List-Id to be the From name of the sender for such cases,
so that the list management options menu has some where to hang itself off.
(But skip this for All headers mode, because there people want to see exact headers, presumably.)

Comment 53

[Magnus Melin [:mkmelin]]

I think we're done here. Will open another bug for exploring UI improvements around this.