Version: 1.5 (using KDE KDE 3.1) Installed from: Unspecified Linux Compiler: gcc 3.2 KDE came in binary format with Linux distribution OS: Linux The problem occurs when receiving messages with international character coding and Content-Type header set to the us-ascii. I need the filter to change ALL instances of Content-Type header rather then just an arbitrary one. I believe replacing all instances of a header is perfectly allright as in the following exaple. Original header: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0-2095903900-1056009676=:5820" X-Spam: Not detected Status: RO X-Status: O X-KMail-EncryptionState: N X-KMail-SignatureState: N --0-2095903900-1056009676=:5820 Content-Type: text/plain; charset=us-ascii The filter is set to rewrithe Content-Type header by looking for us-ascii and replacing it with koi8-r so that the header will read Content-Type: text/plain; charset=koi8-r which is the proper ecoding. Since filter looks up only arbitrary header, there is no effect. Using "delete header" option will not work properly: MIME-Version: 1.0 X-Spam: Not detected Status: RO X-Status: O X-KMail-EncryptionState: N X-KMail-SignatureState: N --0-2095903900-1056009676=:5820 Content-Type: text/plain; charset=us-ascii The last two lines will be now treated as message body. I believe simply replacing the pattern in all headers is more simple and streightforward approach, and that's what expected. If the substring is to be replaced in a header, all instances should be changed at the same time. In the example above the "us-ascii" substring is not found in the first occurance of Content-Type header, so it remains intact. Far more advanced task is re-writing From, To, Reply-To and Subject headers to include character coding string. These should be changed for example from From:
You know that the senders should fix their mail clients on their ends, right? You're trying to fix invalid mail messages (that violate standards). For instance, if I had received one of those through my ISP, it would no longer be fixable because they make the fine gesture of replacing all invalid characters with X. I'd have received: From: XXXXXX <jprst@yahoo.com> Subject: Re: XXXXXXXX! One could say that you're trying to fix the horn because the car brakes aren't working. Now, guessing character coding... that's why there are standards. RFC 2046 says that the character coding is specified in the Content-Type header, so there's no guessing. And if I remember correctly, it also says that the coding is US-ASCII if there's no further information. RFC 2047 specifies how to code the From, To and Subject fields of the message itself, again specifying character coding. Unescaped sequences are invalid (RFC 2047 and RFC 2822 probably). But having a rewrite filter that replaces all instances of something could be useful. If it's integrated into the MIME tree handler, one could add nifty things like "if there's a text/html part" or, like in your case, "text/plain; charset=us-ascii"
*** Bug 61822 has been marked as a duplicate of this bug. ***
shortening summary. I don't even understand the wish
For more complex operations on messages you better use the Pipe Through filter action. You can filter your messages e.g. by a Perl script an do whatever you want. As always, have a look at the KMail handbook (Filters section) before starting.