Add Mail-Followup-To headers and functionality

Hi Ulrich, if you get tired of doing bug fixes and want to do something new, this would be a very nice addition to work on. VM will need this anyway, once the standard catches on.

The IETF draft is from 1997 and hasn't resulted in a standard yet, so I wouldn't expect that anytime soon.

Nevertheless this looks useful and also shouldn't be difficult to implement. But for the time being, there should be an option to enable it, so that VM's default will conform with the standard (which doesn't define this header).

> But for the time being, there should be an option to enable it

To clarify: I meant that the default should be to ignore the MFT header, and we should have an option to enable it. Is "vm-honor-mail-followup-to" a good name (there is already "vm-honor-mime-content-disposition")?

Do we need a separate option for "Mail-Reply-To:"?

Ulrich Müller writes:

> To clarify: I meant that the default should be to ignore the MFT header,
> and we should have an option to enable it. Is "vm-honor-mail-followup-
> to" a good name (there is already "vm-honor-mime-content-disposition")?

Good name!

> Do we need a separate option for "Mail-Reply-To:"?

Yes. I think so.

Cheers,
Uday

The part for receiving mail is done, see revision 637 in my ~ulm/vm/experimental branch. There are two new boolean variables vm-honor-mail-followup-to and vm-honor-mail-reply-to.

I'm not completely sure how to control behaviour when sending. Would something like the following be reasonable, to be implemented in vm-mail-internal:

  - If vm-honor-mail-followup-to is non-nil,
    and the "To" address is found in a list of subscribed mailing lists
    (follow thunderbird and call it vm-subscribed-mailing-lists?)
    then add a MFT header containing the "To" address.

  - If vm-honor-mail-reply-to is non-nil,
    and the "To" address is found in vm-reply-ignored-reply-tos,
    then add a MRT header containing:
      - the address from mail-default-reply-to (if it exists),
        or the vm-mail-header-from address.

Should the vm-reply-ignored-reply-tos variable be reused here, or should we introduce yet another custom variable (vm-reply-to-mangling-mailing-lists?). VM already suffers from having too many custom variables.

Hi Ulrich, Great to see things moving again!

> The part for receiving mail is done, see revision 637 in my
> ~ulm/vm/experimental branch. There are two new boolean variables vm-
> honor-mail-followup-to and vm-honor-mail-reply-to.

Should we set these to t by default? Most users won't bother
otherwise.

> - If vm-honor-mail-followup-to is non-nil,
> and the "To" address is found in a list of subscribed mailing lists
> (follow thunderbird and call it vm-subscribed-mailing-lists?)
> then add a MFT header containing the "To" address.

Yeah, that sounds right.

> - If vm-honor-mail-reply-to is non-nil,
> and the "To" address is found in vm-reply-ignored-reply-tos,
> then add a MRT header containing:
> - the address from mail-default-reply-to (if it exists),
> or the vm-mail-header-from address.

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?

Cheers,
Uday

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

    '(("\\`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.

Ulrich Müller writes:

> 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:
>
> '(("\\`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.

Good idea. Regexps would be consistent with other such alists VM
already has. I myself actually put strings in them. Even though the
'.'s have semantics, they usually work fine.

Cheers,
Uday