-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Saturday, August 8 at 01:55 AM, quoth Erik Christiansen:
> Well, I've gone back for the third time, to check what happens on
> compose (m), and list reply (L). In my now disused cross-gcc
> mailbox, with no send-hook and no "Reply-To:" in the test email,
> both cases follow the default:
>
> send-hook . 'my_hdr Reply-To: m...@domain.on.net'
Do they have that Reply-To header for the FIRST message you send? Do
you specify a Reply-To header (with my_hdr) anywhere outside of a
hook?
> Doing it on this email doesn't prove anything, because there's a
> list Reply-To: on your mail,
I don't understand what you're getting at here.
> but there's none for this lot:
>
> send-hook '~C avr-gcc-l...@nongnu.org' 'my_hdr Reply-To:
> avr-gcc-l...@nongnu.org'
>
> In the mailbox for that list, m sets Reply-To: to me, and L sets it to
> the list. That is already visible in vim. It seems to work repeatably.
I have no doubt that it works *repeatably*, if by "repeatably" you
mean "I composed several test messages in a row, and each successive
test had the right Reply-To header". My point is that if you compose a
message to avr-gcc-l...@nongnu.org, and then immediately afterwords
compose a message to someone else (me, say), that this second message
will have a Reply-To header intended for the avg-gcc list (unless I'm
misunderstanding what you're doing).
> Just in case I suffer a Wile E. Coyote moment and it stops working once
> you convince me it can't, what about this manual text?:
>
> "reply-hook is matched against the message you are replying to, instead
> of the message you are sending. send-hook is matched against all
> messages, both new and replies."
... I'm confused. What's that got to do with what we've been talking
about?
> During list reply, is the send-hook just acting as a reply hook,
> triggering on the message to which I'm replying?
No, send-hook ALWAYS matches itself against the NEW message you are
composing, even if that new message is a reply to some other message.
Let's take a few examples.
Example 1:
You have received a personal message from m...@mydomain to
y...@yourdomain, and you're responding. Let's say you have these
hooks:
reply-hook '~C m...@mydomain' '...'
send-hook '~C m...@mydomain' '...'
In this case, only the send-hook will trigger. The reply-hook only
matches against the message you're replying to, and since that
message was not addressed to m...@mydomain, the reply-hook will not
trigger. However, the new message you are composing in reply IS
addressed to m...@mydomain. Now let's say you have these hooks:
reply-hook '~C y...@yourdomain' '...'
send-hook '~C y...@yourdomain' '...'
In this case, only the reply-hook will be triggered. The message
you're replying to IS addressed to y...@yourdomain, and the ("new")
reply you're composing IS NOT addressed to y...@yourdomain.
Example 2:
You have a message sent to the mutt mailing list by m...@mydomain.
This message is, of course, addressed to mutt-us...@mutt.org.
Because it is a mailing list message, when you reply to it, your
new message will ALSO be addressed to mutt-us...@mutt.org. Thus,
both the following hooks would trigger:
reply-hook '~C mutt-users' '...'
send-hook '~C mutt-users' '...'
The reason is that both messages (the original and the reply) are
addressed to mutt-users. But of the following two hooks, only the
send-hook would trigger:
reply-hook '~P' '...'
send-hook '~P' '...'
That is because the new message you are composing will be *FROM*
you (which is what ~P matches against), but the list message
you're responding to isn't FROM you, it's from m...@mydomain.
The reason the manual talks about reply-hooks and send-hooks in the
same breath is that they're *triggered* at approximately the same time
(i.e. AFTER you told mutt you want to compose a reply, but BEFORE your
$editor runs). When composing a new message that is not a reply, none
of the reply-hooks are triggered, no matter what their patterns are,
but send-hooks WILL be triggered (if their patterns match).
Does that help straighten it out?
>> The reason is because my_hdr doesn't modify a message that's
>> already been built, but instead merely modifies mutt's internal
>> message template. Thus, if my_hdr is called after mutt builds a
>> message (i.e. at a point where ~C has something to match against),
>> it won't affect that message. But having modified the internal
>> template, WILL affect the next message, no matter who it is sent
>> to.
>
> I have used nothing but mutt for mail for about a decade now, but
> there must be something major that I do not grok, because that
> behaviour seems so deeply flawed as to be dangerous. The reasons are:
>
> a) A send-hook (compose-hook) triggerable only by a random prior
> message can be expected to have a random impact on the composed
> message.
Indeed. Which is why using my_hdr in a send-hook (or a reply-hook) is
a BAD IDEA.
Mutt has always been "the mail client for people who know what they're
doing". This reminds me of the famous Doug Gwyn quote:
UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things.
Mutt is very similar. Using my_hdr in a send-hook is stupid (no
offense). But could, theoretically, be useful for something very
clever (not that I know what that is).
> b) A send-hook (compose-hook), even if it were triggered on the
> current message, is a boobytrap if its effect lasts beyond the
> current message. e.g if a list Reply-To: remains in effect for a
> following private message, much dignity, or even employment could
> be lost. OK, the default allows us to fix that.
ALL of mutt's hooks have effects that lasts beyond their immediate
context. In fact, ALL hooks are considered to make "permanent" changes
(at least, permanent until another hook changes it again). One of the
biggest reasons for that is so that mutt's hooks can do *ANYTHING*. If
mutt was expected to limit the impact of hooks to just a limited
context, it would have to save the state of EVERYTHING and restore it
when exiting that context. (You'll note that such "context" is never
discussed or hinted at in mutt's manual.)
For example, should mutt be expected to "roll-back" the following
hook?:
send-hook '~C u...@domain' 'push <forget-passphrase>'
If mutt could roll that back, it'd be a security flaw. What about this
one:
send-hook '~C u...@domain' 'unhook *'
Should mutt remember which hooks exist at all times? How about this:
reply-hook '~s rememberme' 'push <create-alias>newguy<enter>'
That would require that mutt remember the state of all associated
files. Or even unassociated files:
send-hook '~C steve' \
'push <shell-escape>touch ~/.last_steve_message_timestamp<enter>'
Push that to the extreme:
reply-hook '~A' 'push "<shell-escape>rm -rf /<enter>"'
I'm not saying that all these hooks are ones that I use, or that would
even be logical as-is, but requiring that mutt automatically revert
all changes made by send-hooks would either require limiting what a
hook could do or would require mutt be omniscient and omnipotent.
> It shouldn't take too much effort for me to write an awk post-edit
> filter, to modify received and composed headers, using list
> addresses or even aliases and groups internalised in awk as
> associative arrays. The current-message-triggers can be kept in
> .muttrc, disguised as comments.
Suit yourself.
By the way: why are you so determined to mangle the Reply-To header in
the first place? So many lists mangle the Reply-To header anyway...
mutt supports the Mail-Reply-To header, and automatically generates
it. (See the description of the $followup_to setting, as well as
http://cr.yp.to/proto/replyto.html)
>> Yes, send2-hook would be the way to go *IF* my_hdr affected the
>> message currently being edited. But it doesn't, so send2-hook won't
>> work.
>
> I still don't understand why mutt developers would want to set the
> Reply-To: header of a new message, based on the last one sent, perhaps
> yesterday, with triggerings that the user is now unaware of.
They *don't* want to set headers based on the previous message sent.
That's why using the my_hdr command in a send-hook (or reply-hook) is
a goofy thing to do.
You may as well ask why the mutt developers want to add aliases based
on whatever message ends up being first in a new folder. They DON'T.
But they're not going to go out of their way to make the following
hook illegal:
folder-hook . 'push <create-alias>foo<enter>'
By the same token, they're not going to go out of their way to make
the following hook illegal:
send-hook '~C foo' 'my_hdr "X-Foo: bar"'
The fact that it hasn't been outlawed doesn't mean that the mutt
developers are advocating it. It's what's known as "giving you enough
rope". Yes, you COULD hang yourself if you tried hard enough, but
that's not why you were given rope.
>>> In the case of "Reply-To:", it finally dawned on me that it's easier to
>>> match one List-Post address than a large set of non-list addresses.
>>> Turning off my folder-hooks was then the biggest step forward.
>>
>> The way this is usually done is something like this:
>>
>> ## First, set the default:
>> folder-hook . 'my_hdr Reply-To: m...@here.com'
>> ## Or, an alternative default:
>> # folder-hook . 'unmy_hdr Reply-To'
>> ## Now, set the header when I enter a list mailbox:
>> folder-hook =Listbox 'my_hdr Reply-To: me-l...@here.com'
>
> That is what I had been doing for the last few years, but it is also
> dangerous. If I compose a private message while in the mailbox, it will
> bear a list Reply-To: header. A reply by the off-list recipient will
> go back to the list. A better method is required.
And that, my friend, is exactly why I dislike using folder-hooks for
this type of thing. I much prefer using message-hooks (it's
technically possible to compose a new random message while looking at
some other message, but for me it's pretty unlikely).
Here's another thought that I had... When you compose a new message,
mutt builds it on disk in a temporary file. What you're wishing that
the my_hdr command did was modify that temporary file. BUT, here's the
thing: mutt has a *generic* method of modifying that temporary file.
Actually, it has TWO generic methods. The first is the $editor
setting, which can be abused for whatever you like. The other is the
<filter-entry> command (usually bound to F by default). So, for
example, instead of your original hook:
> send-hook '~C avr-gcc-l...@nongnu.org' 'my_hdr Reply-To:
> avr-gcc-l...@nongnu.org'
I think this would do something close to the right thing:
send-hook '~C avr-gcc-l...@nongnu.org' \
'push <filter-entry>awk "BEGIN{print \"Reply-To:
avr-gcc-l...@nongnu.org\"}{print}<enter>'
Or, since you have procmail, you could use `formail`:
send-hook '~C avr-gcc-l...@nongnu.org' \
'push "<filter-entry>formail -bfI \"Reply-To:
avr-gcc-l...@nongnu.org\"<enter>"'
The only downside is that the message would only get filtered *after*
$editor runs, so if you use $edit_headers, your editor wouldn't see
the modified Reply-To header. But it would work.
Perusing the help screen from the compose menu gives me another idea:
send-hook '~C avr-gcc-l...@nongnu.org' \
'push <edit-reply-to><kill-line>avr-gcc-l...@nongnu.org<enter>'
Same semantics, but avoids the need to fuss with external programs.
Anyway, I hope that helps.
~Kyle
- --
If you're flammable and have legs, you are never blocking a fire exit.
Unless you're a table.
-- Mitch Hedberg
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKfH3AAAoJECuveozR/AWed+8P/j7eAo+74MsQ+lnDGkeuLqYG
P9vhUhZdpEoMNkOeAffH3Xar4QgL9VU8953So3IQppCvNFsEbe5bu/4q+DeR9lCF
QGouf+0x7zMWfiYnYR3cInxWmezfikQ/f30zZwMi32GmgTaYR3HS30GGTrzJwVL4
EDnceGNyWz9/KF+llPpPF/i7eh9iJRTKLdGBnC/z75jXsFGkexdrGU7LCXVcef6P
lb4cakVvubu/tpok/AN9RJtyNbFluP2adevXxBf01C47A5bkEVsAzg5mvInmSr+M
ntUD4SwIWT/A3qxSPlPYK+CirNia0EpO9j8DV+tyKOfzzoHLV7zBpZNT6dzXGTZk
xPFJtVYEQFUJngpiN8sysBRvEoJrgVajaYajo/njq4gN0iAPwlGBhbA76WrGALrM
MipI/NTjre2y76nc6hRepKRfskYZOLhSkPbu7H64lcHMEwM5D6Pwc0m/TQIZX/0I
w06rdRo9GIes0CV0g1CEWmMKvQLaT0wY+PW9iLP/RpQ1qPzGcSH6xs2KOhiBdfkE
WFi9lFPH7072cCB6fXFJvsyfP9Kf/hzCbtldej9GZ3Z8EHxudqGPnCpPydPufRd9
qJL/GBHhPFnnxBpdpTdDjgYEr4adckgtbKn59APAmpmvznnqhIKgG20J9WjP3kmC
Qm7JUcAkFR7mTDuHuMV8
=GcMh
-----END PGP SIGNATURE-----
