<<< Date Index >>>     <<< Thread Index >>>

Re: Checking envelope-to header for reverse_name ?



On Thursday, June 11 at 11:44 PM, quoth Heinrich Langos:
mailers) will create a "References:" header that labels your message as being a response to that other thread. Many mail programs, including mutt and most mailing list archive software, will then treat your message as being part of the thread you replied to, which makes those archives confusing to people who are looking for help.

When exactly are "References:" headers added? Sorry to digres but I am curious if my solution of deleting the "In-Reply-To:" header is sufficient.

According to the FAQ (I didn't know this), mutt generates the References header based on the In-Reply-To header, so deleting that header should be sufficient. Personally, though, I think it's better to simply get out of the habit of using "reply" as a way of starting a new message.

That's why I'd rather have it configurable, so that users can specify which other headers to search for a match with their alternates if To: and Cc: (and From:) don't yield a result. Having multiple instances of headers wouldn't hurt, as it doesn't hurt to have multiple Cc: headers.

I think there's a problem here of reliably choosing an address when there are multiple alternatives. Of course, if someone gets a message multiple times via multiple addresses because several of their alternates were CC'd, then mutt has to pick essentially randomly (a simple heuristic like "first good address found" works fine). But that's not a common use-case. However, when handling mailing lists, it is quite common to have multiple Delivered-To headers (or such). I know on my system, every mutt-dev@ email gets at least two Delivered-To headers that contain different valid email addresses for me. On my system the best policy would probably be "last valid alternative found identifies the mailing list recipient" rather than first; but I can easily imagine situations where it's more complicated.

I guess my questions in that case are: how complicated would this "configurable alternatives identification" algorithm need to be? And how would this be "better" than using recipient-based send-hooks?

Ok, most of the mails received from non-lists will probably have my address in the To or Cc. But the manual setup for each list is a big minus.

Mutt already expects you to do some manual setup for each list to get full functionality (see the "list" and "subscribed" commands).

Plus: once you get it set up, how often will you have to modify it? In the past five years I think I've touched that file maybe once. I subscribe to a lot of different mailing lists, but I only post regularly to a very few, and that set doesn't change much. Manually identifying the ones I post to in my config isn't much of a hassle for me. But to each their own.

I was under the impression that reply-hooks are a special case of send-hooks thus I was hoping that putting the send-hook with unmy_hdr before the reply-hook that sets my_hdr again to "From: %y".

Reply hooks can be *thought* of as a special case of send-hooks, but they are their own kind of hook and as such they get triggered independently. I believe, but I haven't tested, that all matching reply-hooks get triggered BEFORE all matching send-hooks. (I tend to avoid relying on different kinds of hooks interacting much, because mutt only guarantees ordering of hooks within a single type.)

Good luck!

~Kyle
--
Old boys have their playthings as well as young ones; the difference is only in the price.
                                                  -- Benjamin Franklin

Attachment: pgpOlfbtLH5T1.pgp
Description: PGP signature