procmail キリル文字変換

Question

について話しているようです。RFC 2047：EメールヘッダーのMIMEエンコーディング。それ以来、このRFCは追加のRFCによって拡張され、追加の文字セットを受け入れ、オプションで言語仕様を含みます。

元の電子メールとMIME仕様には、ヘッダーに厳密なUS-ASCIIしか含まれていないという仮定が含まれていたため、ヘッダーエンコーディングはメッセージ本文のMIMEエンコーディングとは全く別の問題です。

形式は次のとおりです。

=? <character-set> [*language] ? <encoding-letter> ? <text> ?=

<encoding-letter>Q（印刷可能な引用符の場合）またはB（base64エンコーディングの場合）。メッセージが完全に意味がないように見える場合は、base64が表示されています。文字セット名またはエンコーディング文字は大文字と小文字を区別しません。

したがって、以下を見ることができます。

Subject: =?utf-8?b?SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSB1bmRlcnN0b29kIHRoZSBleGFtcGxlLgo=?=

または言語IDを追加してください。

Subject: =?utf-8*en?b?SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSB1bmRlcnN0b29kIHRoZSBleGFtcGxlLgo=?=

手動デコードの例：

$ echo "SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSB1bmRlcnN0b29kIHRoZSBleGFtcGxlLgo=" | base64 -d
If you can read this, you understood the example.

既存のProcmailスクリプトに強制タグ文字セットエンコーディングが含まれているという事実は、iso-8859-1実際の問題が誤ってタグ付けされた文字エンコーディングである可能性があることを示しUS-ASCIIていますUNKNOWN-8BIT。windows-1251言い換えれば：

古い電子メールクライアントはwindows-1251キリル文字をエクスポートしますが、ヘッダーにキリル文字として表示しません。
その過程で、電子メールは8ビットのメールエンコーディングをきちんと処理できると正しく宣言しないか、通常のUS-ASCII以外のすべての文字セットにタグを付けたいメールサーバーを通過します。

この場合、MTAはメッセージを転送するために8ビット文字をエンコードしてタグ付けする必要があります。ただし、8ビット文字にタグが付けられていない場合、元のメールクライアントだけが文字セットが実際に何であるかを確認できます。

実際、文字セットにラベルを付けるという問題は、文字セットを識別するためにコンテンツが特定の文字セットとして解釈されるのが適切であるかどうかを知るために、人間レベルの理解が必要になることです。したがって、時には間違った経験的方法を使用することがあります。

たとえば、実際に正しくエンコードされた電子メールを受信した場合、iso-8859-1スクリプトはそれを誤ってマークし、windows-1251北欧/西ヨーロッパのアクセント文字が無意味なキリル文字で表示されるようにします。ただし、windows-1251誤ってマークされたエンコードされたメッセージを受信するよりもまれな場合は、リスクを取ることをiso-8859-1選択することもできます。大丈夫です。

ヘッダーが実際にどのようにエンコードされたかを調べるには、問題のメッセージを調べる必要があるようですSubject:。彼らは：

ラベルのない一般windows-1251？
base64実際に有効なUTF-8エンコーディングですか？
それともエンコードされ、UTF-8で誤ってタグ付けされwindows-1251ましたか？base64

残念ながらprocmail、そのコンパニオンだけではエンコードされていない形式のヘッダーをformail取得するのに十分ではないかもしれません。Subject:彼らは持っている2001年以降維持されないと作者でさえ、別のものに切り替えることをお勧めします。。ただし、procmail今すぐ使用するには、次のスクリプトのようなものが必要です。

https://github.com/akkana/scripts/blob/master/decodemail.py

私は約10年間重要なスクリプトを実行していないprocmailので、以下の例が間違っている可能性があり、これを行うより良い方法があるかもしれません。ただし、トラブルシューティング方法を説明するのに役立ちます。

まず、Subject:ヘッダーの内容をデコードして変数に保存する必要があります。

:0 h
SUBJDECODED=| decodemail.py Subject:

:0 h
SUBJWASRAW=| formail -xSubject: | recode windows-1251..UTF-8

誤ってマークされたエンコーディングを修正するには、実際の文字セットの文字セットをシステムで使用されているUTF-8に再エンコードする必要があります。

SUBJWASWIN1251=`echo "$SUBJDECODED" | recode windows-1251..UTF-8`

可能なエンコーディングが複数ある場合は、これらの変数を複数作成する必要があります。

その後、テーマのすべてのバージョンと一致させることができます。

:0
* SUBJWASRAW ?? your-subject-regexp-here
{
    # Here the subject was raw windows-1251 without any encoding at all.
    # The variable has it converted to valid UTF-8 used by this system,
    # so now the header can be rewritten in an useful form.
    # (This example leaves the subject as raw unlabelled UTF-8 which 
    # may or may not be acceptable to whatever you use to view your email with.
    # But on modern RFC 6532 compliant mail clients 
    # in a system that uses UTF-8 throughout it may actually be OK.)

    :0 f
    | formail -i "Subject: $SUBJWASRAW"
}

:0
* SUBJWASWIN1251 ?? your-subject-regexp-here
{
    # regexp matched, so we know the subject was windows-1251 
    # mislabeled as UTF-8. Fix it.
    :0 f
    | formail -i "Subject: $SUBJWASWIN1251"
}

:0
* SUBJDECODED ?? your-subject-regexp-here
{
    # regexp matched to subject decoded according to existing label
    # so we know that it was validly labelled. But it still needs to
    # be rewritten as it may have been something other than UTF-8.
    :0 f
    | formail -i "Subject: $SUBJDECODED"
}

# Any further rules should be able to match on the subject as usual.

注：変数にはプレフィックスのみがyour-subject-regexp-here含まれるため、正規表現にはプレフィックスを含めないでください。^Subject:.*値タイトルSubject:。

Answer 1