Неверный порядок файлов в образе MySQL Docker с Debian в качестве основы

Похоже, вы имеете в виду RFC 2047 :Кодирование MIME для заголовков электронной почты . С тех пор другие RFC дополнили этот RFC, чтобы разрешить больше наборов символов и опционально включить спецификацию языка.

Поскольку в первоначальных спецификациях электронной почты и MIME предполагалось, что заголовки будут содержать только строгий US -ASCII, кодировка заголовка — это совершенно отдельная проблема от кодировки MIME тела сообщения.

Формат:

=?  [*language] ?  ?  ?=

будет либо Q для печати в кавычках -, либо B для кодировки base64. Если сообщение кажется совершенно бессмысленным, я предполагаю, что вы видите base64. И имя набора символов, и буква кодировки нечувствительны к регистру -.

Так что вы можете видеть:

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

Или с добавленным идентификатором языка:

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?
• или windows-1251, который былbase64-закодирован и неправильно помечен как UTF -8?

К сожалению, procmailи его аналог formailмогут оказаться недостаточными для получения заголовка Subject:в незакодированной форме. Они не поддерживаются с 2001 года , и даже их автор сейчас предлагает перейти к чему-то другому . Но если вы хотите пока продолжать использовать procmail, вам понадобится что-то вроде этого скрипта:

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

Я не писал существенных procmailсценариев около 10 лет, поэтому приведенный ниже пример может быть неправильным или может быть лучший способ сделать это. Но, возможно, это полезно для объяснения того, как можно решить проблему...

Вам нужно будет сначала декодировать содержимое заголовка 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:.