IMO the default behaviour should be to follow RFCs, and both MFT and MRT are non-standard headers which shouldn't be enabled by default.
> Most users won't bother otherwise.
How about adding a "mailing lists" section to the manual, where all these things could be mentioned?
> Ok, that sounds Thunderbirdish. But I think
> vm-reply-ignored-reply-tos is a very confusing name. I never knew
> what it was for. Why don't we rename it to
> vm-reply-to-mangling-mailing-lists?
Thinking about it again, I believe that we should introduce a single
variable like vm-mailing-list-options-alist to control the various
options. It could look like this:
Open question: Should the CAR elements be regexps or strings? Regexps would be more flexible and allow matching for several lists at one server, and are already used with vm-reply-ignored-reply-tos. Strings would be simpler of course.
> Should we set these to t by default?
IMO the default behaviour should be to follow RFCs, and both MFT and MRT are non-standard headers which shouldn't be enabled by default.
> Most users won't bother otherwise.
How about adding a "mailing lists" section to the manual, where all these things could be mentioned?
> Ok, that sounds Thunderbirdish. But I think ignored- reply-tos is a very confusing name. I never knew to-mangling- mailing- lists?
> vm-reply-
> what it was for. Why don't we rename it to
> vm-reply-
Thinking about it again, I believe that we should introduce a single list-options- alist to control the various
variable like vm-mailing-
options. It could look like this:
'(( "\\`emacs- devel@gnu\ \.org\\ '" mft) ".*@lists\ \.launchpad\ \.net\\ '" mft) "\\`reply- to-mangling@ list\\. example\ \'" mft mrt ignore-reply-to))
(
(
Open question: Should the CAR elements be regexps or strings? Regexps would be more flexible and allow matching for several lists at one server, and are already used with vm-reply- ignored- reply-tos. Strings would be simpler of course.