>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
[email protected]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
