Well, on second thought I don't exactly agree: 1) in reality I often modify the
Subject:, which I can't do if they are encoded, 2) I'm guessing down on the
farm almost all mail bits (MTAs and MUAs) will correctly handle plain Subject:
headers with raw UTF-8, and 3) down on my farm msgs with RFC2047 headers
actually decode to plain text ASCII--they are only RFC2047 encoded because some
Verizon smart phone MUA (or perhaps the email.com MTA) insist on it.
You really modify subject headers that often? I can say that I almost
never do that. Actually, scratch that ... I NEVER do that.
I would not be so sure about 2) ... I know that Cyrus IMAP used to reject
mail messages with headers that contained non-ASCII characters. And to
me the biggest problem is the encoding contains the only place where the
character set is listed. The only times I've seen "bare" UTF-8 is in
spam messages. Maybe it works fine, but at the very least you're going
to have character set issues.
As for 3) ... okay, I've seen that.
So I'd like to intelligently decode the Subject: (not duplicate Re:). Is that
possible? Using...
Subject %<(decode{subject})Re: %(decode{subject})%>
Errr ... it doesn't? Seems to me like it should. Well, maybe you shouldn't
use %(decode{subject}) as the test ... but it looks like to me that that
should work, and I tested it with "ap" and it seemed to do the right thing.
And I even tested it in my replcomps and it worked, although the key line
in my replcomps looks like this:
%<{subject}Subject: Re: %(decode{subject})\n%>\
What happens when you try to use it?
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers