On Thursday, June 11 at 08:02 PM, quoth Heinrich Langos:
I am using address extensions to separate a number of lists that I subscribe to (e.g. user-foo@xxxxxxxxxxx to subscribe to the foo list and user-bar-devel@xxxxxxxxxxx to subscribe to a bar development list.)
Cool - so do I.
Now I'd like to use reverse_name to reply to mails that arrive via those lists. The problem is that on mosts lists my address will not be in To: or Cc: and thus mutt defaults to "From: user@xxxxxxxxxxx" instead of "From: user-foo@xxxxxxxxxxx".
HEH! I'd *like* to use $reverse_name as well, but you've hit the nail on the head: it doesn't apply, because your address may not show up in the message ANYWHERE. (Yes, for many lists, your subscribed address shows up somewhere, and many MTAs create a 'Delivered-To:' header that records what address the message was sent to, but these are unreliable methods.)
So, to keep it short: you CAN'T use $reverse_name to do this.
I like to have incoming mail in _one_ folder only so I can't use folder hooks to solve this.
Lots of people abuse folder-hooks for things they aren't really good for. Mailing lists are one of them. In my personal opinion, folder hooks are good for changing settings that apply to the display of the relevant folder; using them to change how you SEND email is... like using time-of-day to determine whether you ought to put ketchup on your food. Lots of times it's a simple heuristic, but if I want to have a hamburger a 8am, or pancakes at 5pm, things go awry. It's better to serve ketchup depending on what you order. (okay, so it's a strained metaphor, but you get my point.)
Use send-hooks.
What is needed is a way of accessing the envelope-to header in set_reverse_name() to check agains my alternates if "To:" and "Cc:" don't contain any of my alternates.
Meh, that's a fragile and unreliable method. There's no standard way of determining the envelope-recipient once the message has been delivered. Some MTAs create an Envelope-To header, some create a Delivered-To header (sometimes several, if the message has been forwarded), some record the recipient in the Received: headers... it's a mess.
One half baked workaround that I implemented so far is:
Ick.Here's how I do it: I have a file that describes all my mailing lists. Each mailing list gets a similar block of muttrc commands. For example:
# Default settings:
send-hook . unmy_hdr From:
send-hook . set signature="~/.conf/mutt/sigprog|"
# Different return addresses for different mailing lists
subscribe '^mutt-users@mutt\.org$'
send-hook mutt-users@xxxxxxxx \
my_hdr From: Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>
alternates '^kyle-mutt@memoryhole\.net$'
subscribe '^mutt-dev@mutt\.org$'
send-hook mutt-dev@xxxxxxxx \
my_hdr From: Kyle Wheeler <kyle-mutt-dev@xxxxxxxxxxxxxx>
alternates '^kyle-mutt-dev@memoryhole\.net$'
Now, you said that:
Using a send-hook with "unmy_hdr From:" removes that header when newly composing emails but also for replies. :-/
Yes, obviously, but so what?First of all, if you're using vanilla mutt, as long as you have $from (and $realname) set, that's what will be used for non-mailing-list messages. There are some patches out there (e.g. one of the ones that Debian/Ubuntu use on mutt) that make unmy_hdr remove the From header ENTIRELY, which is absurd and broken. I wish I knew which patch they use that does that, so that I could insult that patch publicly and warn people off of it, but I haven't investigated (whatever it is, the problem does not infect my personal mutt build).
However, since my_hdr commands override each other, you can simply use my_hdr to specify a default From header rather than using unmy_hdr, like so:
send-hook . my_hdr From: Kyle Wheeler <me@xxxxxxxxxxx>
See if that doesn't work for you.
~Kyle
--
I would therefore like to posit that computing's central challenge,
how not to make a mess of it, has not yet been met.
-- Edsger Dijkstra
Attachment:
pgpEcIkTwACW4.pgp
Description: PGP signature