Re: Checking envelope-to header for reverse_name ?
Hi Kyle,
On Thu, Jun 11, 2009 at 01:39:38PM -0500, Kyle Wheeler wrote:
> First... please don't start a new thread by replying to an unrelated
> email and then changing the subject. Your mailer (mutt, and most other
I'm sorry about that. I use $edit_headers and usually I remove the
"In-Reply-To:" header which seems to do the trick for mutt.
> 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.
> On Thursday, June 11 at 08:02 PM, quoth Heinrich Langos:
>
>> 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.
Agreed, if it doesn't show up ANYWHERE you are pretty lost.
> So, to keep it short: you CAN'T use $reverse_name to do this.
That is unless somebody patches set_reverse_name() to do it.
It doesn't have to be perfect. Finding reverse_name isn't perfect the way
it is now. :-) It just has to be better than it is now.
> (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.)
> ...
>> 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.
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 I'd need to start by extending the ENVELOPE structure by
something like
ADDRESS *other_reverse_candidate;
and filling that list with addresses found while reading the
headers and ecountering the user specified headers.
>
> 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:
> ...
Well, that works for mailing lists but needs manual setup for each
mailinglist. Also, I use extensions for a lot more that only mailing lists.
Nowerdays I give pretty much everybody an address with extension. This
allows me to blacklist addresses if somebody screws up and an address ends
up on spam lists.
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.
> 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?
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".
> 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).
I've built my mutt version from the Debian package sources and I havn't seen
anything like that. By '"unmy_hdr From:" removes that header' I ment that it
reverts to the default. Sorry for the misunderstanding.
> 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.
This overrides the my_hdr set in the reply hook entirely. No luck so far.
But thats a minor problem.
I guess I'll try a mixture of your approach and my patch. If I get annoyed I
might sit down to do that bigger patch to extend the ENVELOPE structure.
thanx for your help so far
cheers
-henrik