Следует ли использовать utf-8 или "utf-8" в качестве значения кодировки в заголовке письма?

Question

При отправке электронной почты на Outlook.com с включенной переадресацией обнаруживается, что пересылаемая почта отклоняется.

При проверке отправленной почты и почты, сидя в почтовом ящике Outlook. Я считаю, что Microsoft по существу переписала части почтового тела.

Например

This is a multi-part message in MIME format.
--=_5226908e44ebc0462f06052400644d2f
Content-Type: multipart/alternative;
 boundary="=_926d2a45bc543e1972443c87118fa61a"

--=_926d2a45bc543e1972443c87118fa61a
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=utf-8

SGF2aW5nIGFub3RoZXIgZ28gYXQgZm9yd2FyZGluZyBhbiBlbWFpbCB2aWEgT3V0bG9vay4NCg0K
DQo=
--=_926d2a45bc543e1972443c87118fa61a
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=utf-8

Становится следующим; обратите внимание на кавычки вокруг значения charset :

--=_5226908e44ebc0462f06052400644d2f
Content-Type: multipart/alternative;
boundary="=_926d2a45bc543e1972443c87118fa61a"

--=_926d2a45bc543e1972443c87118fa61a
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

SGF2aW5nIGFub3RoZXIgZ28gYXQgZm9yd2FyZGluZyBhbiBlbWFpbCB2aWEgT3V0bG9vay4NCg0K
DQo=
--=_926d2a45bc543e1972443c87118fa61a
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

Теперь, кроме того факта, что RFC почты специально запрещают изменять тело в любом случае (что нарушает сигнатуру DKIM), я должен спросить, как правильно написать charset=utf-8 в заголовке письма?

Answer 1

RFC2045 предоставляет в разделе 5.1 грамматику, используемую для построения допустимых заголовков Content-Type в сообщениях MIME:

5.1.  Syntax of the Content-Type Header Field

   In the Augmented BNF notation of RFC 822, a Content-Type header field
   value is defined as follows:

     content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.

     type := discrete-type / composite-type

     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token

     composite-type := "message" / "multipart" / extension-token

     extension-token := ietf-token / x-token

     ietf-token := <An extension token defined by a
                    standards-track RFC and registered
                    with IANA.>

     x-token := <The two characters "X-" or "x-" followed, with
                 no intervening white space, by any token>

     subtype := extension-token / iana-token

     iana-token := <A publicly-defined extension token. Tokens
                    of this form must be registered with IANA
                    as specified in RFC 2048.>

     parameter := attribute "=" value

     attribute := token
                  ; Matching of attributes
                  ; is ALWAYS case-insensitive.

     value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
                   ; Must be in quoted-string,
                   ; to use within parameter values

Обратите внимание, как value определяется как token / quoted-string .

Далее в разделе текстовое пояснение с примером:

   Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with RFC 822 rules for structured header fields.  Thus the
   following two forms

     Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"

   are completely equivalent.

Как видите, цитирование не требуется, если значение уже является token (1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>), но, тем не менее, действительно.

Answer 2

Хороший вопрос. По моему опыту, заголовки электронной почты в формате HTML не слишком сильно отличаются от заголовков в формате HTML (веб-сервер), поэтому я бы предпочел использовать версию без кавычек, например:

Content-Type: text/html; charset=utf-8

И, углубившись в RFC (RFC 2047) для кодирования MIME, я нашел это:

2. Syntax of encoded-words

   An 'encoded-word' is defined by the following ABNF grammar.  The
   notation of RFC 822 is used, with the exception that white space
   characters MUST NOT appear between components of an 'encoded-word'.

   encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

   charset = token    ; see section 3

   encoding = token   ; see section 4

Ни в коем случае не упоминается, являются ли указанные значения токенов действительными или нет. Итак, я собираюсь предположить, что Microsoft каким-то образом переписывает заголовки, чтобы они указывали значения в кавычках? Не могу понять, что было предоставлено, но я предпочел бы использовать значение unquote вместо того, чтобы по умолчанию делать то, что делает Microsoft.