Bug 1441 - Add support for the "Mail-Followup-To"-header
Summary: Add support for the "Mail-Followup-To"-header
Status: RESOLVED WONTFIX
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI (show other bugs)
Version: 3.2.0
Hardware: All All
: P3 enhancement
Assignee: users
URL: http://cr.yp.to/proto/replyto.html
Depends on:
Blocks:
 
Reported: 2007-12-28 16:47 CET by Florian Heimgaertner
Modified: 2008-07-05 15:52 CEST (History)
0 users

See Also:


Attachments
patch for mft+mrt (4.78 KB, patch)
2007-12-31 15:59 CET, Florian Heimgaertner
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Heimgaertner 2007-12-28 16:47:28 CET
The "Mail-Followup-To"-header provides a possibility to override the default selection of recipients used for the "Reply to All"-feature.

Read http://cr.yp.to/proto/replyto.html for more information.

Requested Features:
- (at least optionally) use the data from the M-F-T header for Reply-All
- add "Mail-Followup-To" to the dropdown-list of headers in the compose-window
- add per-folder preference for a M-F-T default value
Comment 1 Florian Heimgaertner 2007-12-31 13:04:56 CET
ok, the per-folder pref is not a good idea. according to the mentioned URL the correct solution is:
"If To or Cc includes a mailing list that the user is subscribed to, create the Mail-Followup-To field from To and Cc alone. You need to let the user tell you which mailing lists he's subscribed to."
Comment 2 Florian Heimgaertner 2007-12-31 15:59:06 CET
Created attachment 526 [details]
patch for mft+mrt

This patch adds support for reading and manually setting Mail-Followup-To and Mail-Reply-To.
I'm not sure, if that's the correct way to do it, but it seems to work.
Comment 3 Colin Leroy 2008-07-05 15:52:44 CEST
-- Bugzilla database cleanup --
Hi, 
It looks like nobody has been interested in implementing this feature since the end of 2007; in order to clean up the bugzilla, I'm marking this WONTFIX.

Features in Claws Mail get implemented on a developer-interest basis: if one of the core developers codes a feature, or if an external contributor provides a good patch, the feature gets added. If the feature interests nobody with coding abilities, although it seems nicer to leave old requests lingering in Bugzilla and let the submitter hope the feature will be added someday, it's more honest (and cleaner) to close them as WONTFIX.