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.

Neat idea. -> 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.

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.

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.

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

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

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

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

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

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.