2015-03-24 2 views
-1

Я столкнулся с некоторыми сообщениями с закодированными словами в адресе электронной почты, например. вместоIndy10 - Закодированные слова по адресу электронной почты

abc <[email protected]>

содержит:

abc <=?ISO8859-1?B?YWJjQGV4YW1wbGUuY29t=?=>

Я видел, что многие почтовые программы имеют проблемы с ним, но некоторые из них не заставляет меня думать, что это может быть частью некоторых RFC, хотя я не могу его найти.

Кроме того, если заголовок адрес электронной почты в виде:

From: =?ISO8859-1?B?YWJjQGV4YW1wbGUuY29t=?=

Это будет декодируются многими программами, но не Инди. То, что происходит в большинстве программ является то, что они считают, что часть а от «имени» части и расшифровать его как таковой, но они оставляют адрес электронной почты кодируются, в результате чего:

Name = [email protected] Email = =?ISO8859-1?B?YWJjQGV4YW1wbGUuY29t=?=

Что делает его, по крайней мере, частично хорошо декодируется.

В Indy, однако это приводит:

Name = **blank** Email = =?ISO8859-1?B?YWJjQGV4YW1wbGUuY29t=?=

Если это будет поддерживаться в Инди (или изменена так, что считает base64 часть, как «имя» часть, а не как «электронная почта» часть) или это неверно отформатированный адрес электронной почты? Или это вопрос интерпретации, который следует интерпретировать как первую часть, поскольку письмо действительно может выглядеть как From: [email protected] без символов <>.

+0

выглядит как base64 кодировка. – Craig

+0

@Craig Конечно, это base64, но проблема заключается в том, что адрес электронной почты является кодированной, а не частью «имени». – Coder12345

+0

Какая сборка indy10 вы используете? У меня тоже была эта проблема, но я считаю, что она исправлена ​​в более поздних версиях. – whosrdaddy

ответ

3

< аЬс = ISO8859-1 В YWJjQGV4YW1wbGUuY29t =>

Инди не поддерживает такие кодированные адреса, за RFC 2047 Section 5 Use of encoded-words in message headers:???

An 'закодированный-слово' могут появляться в заголовке сообщения или заголовке части тела в соответствии со следующими правилами:

(1) «Закодированное слово» может заменить токен «текст» (как определено RFC 822) в любом предмете или Поле заголовка комментариев, любое поле заголовка сообщения расширения или любое поле части тела MIME, для которого тело поля определено как «текст». «Закодированное слово» также может отображаться в любом пользовательском («X-») сообщении или в заголовке части тела.

Обычный текст ASCII и «кодированное слово» могут отображаться вместе в одном заголовочном поле. Однако «закодированное слово», которое появляется в поле заголовка, определяемом как «текст», ДОЛЖНО быть отделено от любого смежного «закодированного слова» или «текста» на «линейно-белое пространство».

(2) «Закодированное слово» может появляться в «комментарии», ограниченном символом «(» и «)», то есть везде, где разрешен «ctext».Точнее, определение ABNF RFC 822 для 'комментария' изменяются следующим образом:

комментария = "(" * (CTEXT/кавычко пар/комментарий/закодированное слово) ")"

А «Q «-кодированное кодированное слово», которое появляется в «комментарии», НЕ ДОЛЖНО содержать символы «(«, »)» или «« закодированное слово », которые появляются в« комментарии », ДОЛЖНЫ быть отделены от любых смежных« закодированных- слово 'или' ctext 'на «линейно-белое пространство».

Важно отметить, что «комментарии только распознаются внутри« структурированных »тел поля. В полях, тела которых определены как« текст », («и») «рассматриваются как обычные символы, а не разделители комментариев, а правило (1) этого раздела х годов. (См. RFC 822, разделы 3.1.2 и 3.1.3)

(3) В качестве замены для слова «слово» внутри фразы, например, такой, который предшествует адресу в From, To, или Cc. Определение ABNF для «» фразы из RFC 822, таким образом, становится:

фраза = 1 * (кодируются слово/слово)

В этом случае набор символов, которые могут быть использованы в «Q» закодирована «закодированное слово» ограничено:. «Закодированное слово», которое появляется в «фразе», ДОЛЖНО быть отделено от любого смежного «слова», «текста» или «специального» по «линейно-белому пространству».

Это ТОЛЬКО места, где может появляться «закодированное слово». В частности:

  • An 'закодированы слово' НЕ ДОЛЖНЫ появляться в любой части с 'Addr-спецификации'.

  • «Закодированное слово» НЕ ДОЛЖНО появляться в «цитируемой строке».

  • «Закодированное слово» НЕ ДОЛЖНО использоваться в поле Received Received.

  • An «закодированного слово» НЕ ДОЛЖЕН использоваться в параметре MIME в Content-Type или Content-Disposition поля, или в каком-либо структурированном теле поля, за исключением в «комментариях» или «фраза».

Инди (и RFC-2047) не поддерживает закодированные имена, хотя:

From: =?ISO8859-1?B?YWJj?= <[email protected]> 

От:??? = ISO8859-1 В YWJjQGV4YW1wbGUuY29t = =

В этом случае Indy интерпретирует это как адрес электронной почты без имени. И, как указано выше, кодированные адреса не допускаются.

+0

Таким образом, разрешены кодированные адреса электронной почты (в пределах '<>'), как указано выше? – Coder12345

+1

Собственно, нет. Смотрите мои правки. –

+0

Использование @themihai символов, отличных от ASCII в адресах электронной почты, зависит от протокола. Например, адрес электронной почты может быть закодирован в UTF-8, если клиент SMTP и сервер поддерживают расширение SMTPUTF8 (которое Indy еще не существует), или если письмо полностью закодировано в UTF-8 (заголовки и тело) с использованием ' сообщение/глобальный тип MIME. –