Closed Bug 29041 Opened 24 years ago Closed 15 days ago

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

Categories

(MailNews Core :: Composition, enhancement, P3)

enhancement

Tracking

(thunderbird_esr115 wontfix)

RESOLVED FIXED
125 Branch
Tracking Status
thunderbird_esr115 --- wontfix

People

(Reporter: jgmyers, Assigned: mkmelin)

References

()

Details

(Keywords: leave-open)

Attachments

(3 files, 1 obsolete file)

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.
Summary: Support mailing list unsubscription headers → Support mailing list unsubscription headers - RFC 2369
Neat idea. -> helpwanted
Assignee: phil → nobody
Keywords: helpwanted
*** Bug 87299 has been marked as a duplicate of this bug. ***
*** Bug 93253 has been marked as a duplicate of this bug. ***
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.
Keywords: mozilla1.1
In the following URL there is a brief explanation how "Pegasus Mail" handles
this feature:

http://www2.angen.net/~pegasus/secrets.html#maillist
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
Isn't implementing this as simple as adding those headers to the list of headers
displayed (currently Subject, From, Date, To, CC)?
> 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. 
*** Bug 159056 has been marked as a duplicate of this bug. ***
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.
*** Bug 167994 has been marked as a duplicate of this bug. ***
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  :-)
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).
I would hope all would be supported, for parity (at least) with other MUAs.
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.
Blocks: 45715
No longer blocks: 45715
Depends on: 45715
Summary: Support mailing list unsubscription headers - RFC 2369 → Support mailing list management (unsubscription etc.) headers - RFC 2369
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. 
bug 45715 specifically refers to the "reply to list" feature
Product: Browser → Seamonkey
This block 45715. If really someone found that it depends on it they are dupe
(despite of Zak Kipling's comment #18
(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...
Please, let us see more work on this. Especially on the Reply-To-List feature.
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...
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
bug 45715 has a patch - requires enigmail or meheny
Component: MailNews: Main Mail Window → MailNews: Composition
Product: Mozilla Application Suite → Core
QA Contact: lchiang → composition
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!
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.
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).
I made two extensions dealing with mailing lists:
mailinglistheaders and replyToList
both can be found at http://cweiske.de/misc_extensions.htm
(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.
Product: Core → MailNews Core

Would love to have this also.

See Also: → 499080
Keywords: helpwanted
See Also: → 1512453
Summary: Support mailing list management (unsubscription etc.) headers - RFC 2369 → Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369
Priority: P3 → P2

This is obviously backlog for now.

Priority: P2 → P3
Severity: normal → S3

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.

Duplicate of this bug: 1850585
Summary: Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369 → Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369 and RFC 8058

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.

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.

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

Summary: Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369 and RFC 8058 → Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED

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.

Attachment #9377960 - Attachment description: Bug 29041 - Part 1: Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369. r=#thunderbird-front-end-reviewers → Bug 29041 - Part 1: Support mailing list management (unsubscribe, subscribe etc.) headers - RFC 2369. r=freaktechnik
Target Milestone: --- → 125 Branch

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

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/c10fd4598917
Part 2: Use List-ID with context menu for list management. r=aleca

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.

See Also: → 512385

Pushed by benc@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/a6e7c670f689
Fix bad interaction of mailnews.headers.extraExpandedHeaders settings and known headers. r=aleca

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

Attachment #9390554 - Attachment is obsolete: true
See Also: → 1885323

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

Status: ASSIGNED → RESOLVED
Closed: 15 days ago
Resolution: --- → FIXED
See Also: → 1885324
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: