Support mailing list management (unsubscription etc.) headers - RFC 2369

NEW
Unassigned

Status

P3
enhancement
19 years ago
11 months ago

People

(Reporter: jgmyers, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Summary: Support mailing list unsubscription headers → Support mailing list unsubscription headers - RFC 2369

Comment 1

19 years ago
Neat idea. -> helpwanted
Assignee: phil → nobody
Keywords: helpwanted
*** Bug 87299 has been marked as a duplicate of this bug. ***

Comment 3

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

Comment 4

18 years ago
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

Comment 6

17 years ago
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

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

Comment 8

17 years ago
> 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

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

Comment 10

17 years ago
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

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

Comment 12

16 years ago
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

16 years ago
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

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

Comment 15

16 years ago
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.

Updated

16 years ago
Blocks: 45715

Updated

16 years ago
No longer blocks: 45715
Depends on: 45715
Summary: Support mailing list unsubscription headers - RFC 2369 → Support mailing list management (unsubscription etc.) headers - RFC 2369

Comment 16

15 years ago
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 18

14 years ago
bug 45715 specifically refers to the "reply to list" feature
Product: Browser → Seamonkey

Comment 19

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

Comment 20

14 years ago
(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

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

Comment 22

13 years ago
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 24

13 years ago
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

12 years ago
bug 45715 has a patch - requires enigmail or meheny

Updated

12 years ago
Component: MailNews: Main Mail Window → MailNews: Composition
Product: Mozilla Application Suite → Core
QA Contact: lchiang → composition

Comment 26

12 years ago
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

12 years ago
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

12 years ago
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).

Updated

12 years ago
Duplicate of this bug: 223129

Comment 30

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

Updated

11 years ago
Duplicate of this bug: 399032

Comment 32

11 years ago
(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.

Updated

11 years ago
Duplicate of this bug: 385541

Updated

11 years ago
Duplicate of this bug: 420116

Updated

11 years ago
Duplicate of this bug: 245029
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.