Эоган Кейси (2004). Цифровые улики и компьютерные преступления: криминалистика, компьютеры и Интернет . Академическая пресса . п. 506. ISBN 0-12-163104-4
.
Резник, П. (4 октября 2008 г.). Резник, П. (ред.). «Формат интернет-сообщений» . Серия RFC . дои : 10.17487/RFC5322 – через www.rfc-editor.org.
Кленсин, Дж. (4 октября 2008 г.). «Простой протокол передачи почты» . Серия RFC . дои : 10.17487/RFC5321 – через www.rfc-editor.org.
Левинсон, Э. (4 августа 1998 г.). «Унифицированные указатели ресурсов Content-ID и Message-ID» . Серия RFC . дои : 10.17487/RFC2392 – через www.rfc-editor.org.
Функции для отправки и получения сообщений
Отправить сообщение в Telegram
Пример кода для рекламы
. message_thread_id)
!
идентификатор_платформы — идентификатор клиента в Telegram, необходимо прислать сообщение
client_message_id – идентификатор сообщения, который необходимо процитировать
answer_markup — настройка кнопок
parse_mode — выделение текста в описании жирным или курсивным
. Может иметь значения html, markdown, markdownV2.
disable_web_page_preview – отобразить превью ссылки. Для использования передайте 1, иначе 0 или есть пустое значение “”
protect_content — признак защиты от продажи. Чтобы включить передайте любое значение, кроме 0, False и пустых кавычек ”
disable_notification — признак отправки сообщения со звуковым уведомлением (по умолчанию 0) 1 – отключить уведомление при получении, 0 – передать с уведомлением
message_thread_id — идентификатор темы (доступно для супергрупп при наличии функционала форума)
Рассмотрим простой пример с набором обязательных параметров:
В качестве platform_id указывается идентификатор конкретного клиента
Тот же пример, но с использованием переменных:
В данном примере в переменной soob будет содержаться ответ сервера после отправки сообщения.
Если сохранить идентификатор сообщения message_id из полученного ответа, то это позволит нам впоследствии работать с данным сообщением (редактировать, удалять, пересылать, комментировать).
Очень часто возникают сложности в использовании всех параметров. Давайте рассмотрим такой пример:
для начала объявите все параметры, используемые в функции. Не забывайте, что параметры можно передать не только значением, но и переменными, что чаще более удобно и наглядно. Такие переменные, как platform_id и client_message_id Вы можете получить в карточке клиента
platform_id — идентификатор клиента в Telegram, которому необходимо прислать сообщение
>Будем отвечать в том же чате, где пишет клиент
text – текст сообщения.
>Используем форматирование текста – например, выделение жирным
client_message_id – идентификатор сообщения, которое необходимо процитировать
>В чатах эта переменная получает свое значение автоматически.
reply_markup — настройки кнопок
.
>Присвоим в переменную opts
parse_mode — выделение текста в описании жирным или курсивом
. Может иметь значения html, markdown, markdownV2. Используемые символы для форматирования текста сообщения описаны
>Используем markdown.
disable_web_page_preview – отобразить превью ссылки. Чтобы отключить передайте 1, иначе 0 или оставьте пустое значение “”
>Мы можем передать любое значение, поскольку в тексте сообщения не указываем ссылку
protect_content — признак защиты контента от копирования. Чтобы включить передайте любое значение, кроме 0, False и пустых кавычек ”
>Нам не требуется защита контента передадим ”
disable_notification — признак отправки сообщения с уведомлением (по умолчанию 0) 0 – отключить уведомление при получении, 1 – передать с уведомлением
>Уведомление – это всплывающее окно с содержимым текста сообщения. Давайте включим
Далее собираем функцию. Не забывайте присваивать функцию переменной – это позволит отследить статус отправки сообщения
Смотрим, что у нас получилось: После того, как клиент написал нам ключевое слово test, мы отвечаем ему, цитируя его сообщение
Пример использования всех параметров функции отправки сообщения
При этом в переменной soob видим следующий ответ сервера:
Ответ сервера после отправки сообщения функцией API
В ok мы как раз видим статус отправки, далее содержится информация о данном сообщении – его id, данные отправтеля, содержимое отправления.
/*Текст удобно предварительно прописывать в переменной*/
/*Функция Отправить сообщение*/
/*Сохраняем ид отправленного сообщения*/
text=’Тестируем отправку сообщения API-методом. Например, *жирный текст*’
token — токен Telegram-бота, полученный в BotFather
!
platform_id — идентификатор клиента в Telegram, которому необходимо прислать сообщение
client_message_id – идентификатор сообщения, которое необходимо процитировать
reply_markup — настройки кнопок
parse_mode — выделение текста в описании жирным или курсивом
. Может иметь значения html, markdown, markdownV2.
disable_web_page_preview – отобразить превью ссылки. Чтобы отключить передайте 1, иначе 0 или оставьте пустое значение “”
protect_content — признак защиты контента от копирования. Чтобы включить передайте любое значение, кроме 0, False и пустых кавычек ”
disable_notification — признак отправки сообщения со звуковым уведомлением (по умолчанию 0) 1 – отключить уведомление при получении, 0 – передать с уведомлением
message_thread_id — идентификатор темы (доступно для супергрупп при наличии функционала форума)
— идентификатор клиента в Telegram, которому необходимо прислать сообщение
!
message_id
– идентификатор сообщения, которое необходимо отредактировать. Предварительно id нужно сохранять при отправке
!
text – текст сообщения
reply_markup — настройки кнопок
parse_mode — выделение текста в описании жирным или курсивом
. Может иметь значения html, markdown, markdownV2. Может иметь значения html, markdown, markdownV2. disable_web_page_preview – отобразить превью ссылки. Чтобы отключить передайте 1, иначе 0 или оставьте пустое значение “”
platform_id — идентификатор клиента в Telegram, которому необходимо прислать сообщение
!
message_id – идентификатор сообщения, которое необходимо отредактировать
!
reply_markup — настройки кнопок
Итак, отправим себе сообщение с инлайн-клавиатурой:
далее отредактируем текст сообщения:
теперь отредактируем кнопки:
Попрообуем отредактирвать сообщение с картинкой. Для этого отправим сообщение с картинкой и сохраним идентификатор отправленного сообщения. О том как получить ссылку на картинку подробно описано
Редактируем картинку и описание:
/*Параметры удобно предварительно прописывать в переменной*/
platform_id — идентификатор группы в Telegram, В КОТОРЫЙ будем копировать сообщение
!
from_chat_id – идентификатор группы в Telegram, ИЗ КОТОРОЙ будем копировать сообщение
!
message_id
– идентификатор сообщения, которое необходимо скопировать reply_to_message_id – идентификатор исходного сообщения, если копируемое сообщение является комментарием
reply_markup
— настройки кнопок
parse_mode — выделение текста в описании жирным или курсивом
. Может иметь значения html, markdown, markdownV2.
protect_content — признак защиты контента от копирования. Чтобы включить передайте любое значение, кроме 0, False и пустых кавычек ”
disable_notification — признак отправки сообщения со звуковым уведомлением (по умолчанию 0) 1 – отключить уведомление при получении, 0 – передать с уведомлением
message_thread_id — идентификатор темы (доступно для супергрупп при наличии функционала форума)
Отправим сообщение и сохраним его идентификатор:
Скопируем ранее отправленное сообщение:
/*Параметры удобно предварительно прописывать в переменной*/
— идентификатор клиента в Telegram, КУДА необходимо переслать сообщение
!
from_chat_id — идентификатор клиента в Telegram, ОТКУДА необходимо переслать сообщение
!
message_id
— идентификатор пересылаемого сообщения
protect_content
— признак защиты контента от копирования. Чтобы включить передайте любое значение, кроме 0, False и пустых кавычек ”
disable_notification
— признак отправки сообщения со звуковым уведомлением (по умолчанию 0) 1 – отключить уведомление при получении, 0 – передать с уведомлением
message_thread_id — идентификатор темы (доступно для супергрупп при наличии функционала форума)
Удалить сообщение в Telegram
Используйте этот метод для удаления сообщения, в том числе служебного, со следующими ограничениями:
Сообщение может быть удалено только в том случае, если оно было отправлено менее 48 часов назад.
Сообщение с кубиками в приватном чате можно удалить только в том случае, если оно было отправлено более 24 часов назад.
Боты могут удалять исходящие сообщения в приватных чатах, группах и супергруппах.
Боты могут удалять входящие сообщения в приватных чатах.
Боты с разрешениями can_post_messages могут удалять исходящие сообщения в каналах.
Если бот является администратором группы, он может удалить там любое сообщение.
Если у бота есть разрешение can_delete_messages в супергруппе или канале, он может удалить там любое сообщение.
!
platform_id — идентификатор клиента в Telegram
!
message_id – идентификатор сообщения, которое необходимо удалить
* Где взять platform_id (owner_id) клиента для отправки уведомлений
** Как прописывать кнопки в параметре keyboard
▶️ Как отправить сообщение во Вконтакте
▶️ Как редактировать сообщение во ВКонтакте
▶️ Как удалить сообщение ВКонтакте
▶️ Как удалить последнее сообщение в беседе во Вконтакте
▶️ Как создать короткую ссылку в Вконтакте
▶️ Как отправить стикер во Вконтакте
▶️ Как отправить несколько картинок во Вконтакте
▶️ Как определить поставил ли пользователь лайк под конкретным объектом во Вконтакте :
▶️ Как исключить пользователя из беседы во Вконтакте :
▶️ Как получить имя пользователя в беседе Вконтакте
▶️ Как опубликовать пост во ВКонтакте
– Как делать репосты постов со стены ВКонтакте
▶️ Как сохранить текст комментария во ВКонтакте :
▶️ Как открыть или закрыть комментирование поста в сообществе во ВКонтакте :
▶️ Удаление комментария со стены
▶️ Как найти сообщение по тексту и получить все необходимые параметры по нему
▶️ Как проверить подписку на сообщество
▶️ Как закрепить/открепить сообщения в чатах сообщества во ВКонтакте
▶️ Как показать пользователю действия бота (печатает, записывает аудио) во ВКонтакте
▶️ Поставить реакцию на сообщение в личных сообщениях или в чатах
Добавить или изменить ранее добавленную реакцию
Удалить ранее поставленную реакцию на сообщение
Получить счетчик реакции на сообщения
▶️ Как работать с Callback-кнопками во ВКонтакте
– Как перейти по ссылке после нажатия callback-кнопки
– Как показать исчезающее сообщение
▶️ Как определить число участников в групповом чате
▶️ Как получить ссылку-приглашение в чат
▶️ Как отметить в сообществе диалог как важный/отвеченный/прочитанный
▶️ Как снять отметку “важно” с диалога или обозначить диалог непрочитанным в сообществе
▶️ Как принять заявку на вступление в группу
▶️ Как работать с черным списком группы
▶️ Как удалить пользователя из группы и всех бесед, созданных в группе
▶️ Как назначить/разжаловать администратора группы и указать/убрать его в списке контактов
▶️ Как распознать текст на изображении
TLDR;
Feel free to skip along to Threading Emails: The Github Approach
if you are in an email thread emergency.
Why do we need email threads?
Email threads help us keep email conversations coherent. Think about the apps we use on a daily basis. We have conversations on Github that result in email notifications that show in a single thread to help us retain context for each notification. Threaded emails also make it much easier to view all the emails related to a single discussion.
For this post we will focus on the mailer part of this feature.
We can create a NotificationMailer like this:
We will get back to Great Books, let us first dig a bit deeper into email headers.
The RFC 5322 – Internet Message Format opens a new window
protocol defines the syntax required by modern email messages. For this post we are interested in the 3.6.4. Identification Fields opens a new window
section. We are specifically interested in the three header fields: Message-ID: , In-Reply-To: and References: described in that section.
Message-ID: поле должно быть уникальным, так как оно используется, чтобы отличить одно сообщение от другой. In-Reply-To: и References: заголовки используются при создании ответа на сообщение. Сообщение, на которое вы отвечаете, также известно как родительское сообщение. Последний заголовки содержат идентификатор сообщения, на которое отвечается, и сообщение идентификаторы других сообщений в потоке.
Message-ID: заголовок содержит единственный уникальный идентификатор сообщения. References:
и In-Reply-To: каждое поле содержит один или несколько уникальных идентификаторов сообщений, необязательно разделенные комментариями, складывающимся пробелом (CFWS) открывает новое окно
. В этом посте мы будем использовать один пробел в качестве разделителя.
Прежде чем мы пойдем дальше, было бы интересно сначала взглянуть на заголовки некоторых писем. В на заре электронной почты заголовки электронной почты показывались вместе с телом сообщения. электронная почта. Современные почтовые приложения скрывают заголовки, чтобы сделать чтение тела письма более удобным. электронная почта проще. Довольно легко выполнить быстрый поиск в Google, чтобы узнать, где вы можете просмотреть заголовки электронной почты для вашего конкретного почтового клиента. Мы найдем минутку, чтобы найти заголовки писем в Gmail.
Мы можем открыть Gmail и выбрать любой адрес электронной почты. Затем мы нажимаем на вертикальное трехточечное меню кнопка. Далее мы выберем Show original вариант. Gmail откроет новую вкладку со всеми заголовки прямо там для нас, чтобы проверить.
Пожалуйста, найдите минутку, чтобы посмотреть, сможете ли вы найти Message-ID , In-Reply-To и References поля в заголовках из вашего почтового ящика.
Наш первый подход
Возвращаясь к Great Books, мы хотели бы отправлять уведомления всякий раз, когда книга рецензируется. Электронное письмо должно быть связано с любым другим уведомлением о рецензировании, отправленным для той же книги в прошлое.
Шаг 1: Метод `message_id`
Первое, что нам нужно сделать, это сгенерировать идентификатор сообщения. Мы должны убедиться, что идентификатор, который мы генерируем, уникален. У нас есть несколько вариантов, чтобы убедиться, что идентификатор сгенерированного сообщения уникальный.
Сгенерируйте и сохраните UUID, который мы можем легко получить всякий раз, когда отправляем новое уведомление:
Я уверен, что мы можем придумать много других уникальных способов генерации идентификатора сообщения. Эти двое примеры должны помочь нам получить хорошее представление о том, как может выглядеть идентификатор сообщения. Если мы выберем вариант 1, нам нужно будет сохранить идентификатор сообщения, потому что мы не будем возможность пересчитать UUID. Итак, чтобы упростить задачу, мы выберем вариант 2.
Во-первых, мы возвращаем пустую строку, если в обзоре передано нулевое значение. В противном случае обратите внимание, что он вычисляет идентификатор сообщения электронной почты на основе некоторого обзора id и created_at время. Это ставит перед словом notification и добавляет доменное имя. Добавляя префикс и suffix мы обеспечиваем уникальность идентификатора сообщения в рамках нашего приложения.
Интересно, что Message-ID это текст между двумя угловыми скобками. требуются угловые скобки, но технически они не являются частью Message-ID .
Шаг 2: Методы `in_reply_to` и `reviews_in_thread`
Согласно RFC:
The “In-Reply-To:” field may be used to identify the message (or messages) to which the new message is a reply. It contains the contents of the “Message-ID:” of the “parent message”. If the reply is part of a thread with multiple parent messages, then the “In-Reply-To:” field will contain the contents of all of the parents’ “Message-ID:” fields. The “In-Reply-To:” header can be omitted if no parent message in the thread has a “Message-ID:”.
Самое сложное, пожалуй, найти Message-ID ранее отправленного уведомления. Итак, мы добавим два метода. Один для получения предыдущих обзоров, а другой для создания In-Reply-To поле. Помните, что нас интересуют только отзывы о конкретной книге, так как все рецензии на эту книгу будут принадлежать одной ветке электронной почты.
Сначала мы добавляем приведенный ниже метод, который извлекает другие отзывы, принадлежащие теме.
Теперь нам нужно сгенерировать контент для In-Reply-To поле заголовка.
Мы принимаем только последний отзыв, так как он будет связан с последним отправленным нами уведомлением. для рецензируемой книги. Таким образом, последним уведомлением является родительский адрес электронной почты уведомление, которое мы сейчас отправляем. Скоро мы объединим весь набор заголовки, но на этом заканчивается In-Reply-To: полевая секция.
Шаг 3: Метод «эталонов»
“References:” field may be used to identify a “thread” of conversation.
…
The “References:” field will contain the contents of the parent's “References:” (if any) followed by the contents of the parent's “Message-ID:” (if any). If the parent message does not contain a “References:” field but does have an “In-Reply-To:” field containing a single message identifier, then the “References:” field will contain the contents of the parent's “In-Reply-To:” field followed by the contents of the parent's “Message-ID:” field (if any). If the parent has none of the “References:”, “In-Reply-To:”, or “Message-ID:” fields, then the new message will have no “References:” field.
Иногда полезно обрисовать сценарий. Итак, давайте рассмотрим, как будет выглядеть этот заголовок как с каждым дополнительным уведомлением.
Первое уведомление не будет иметь References: поле, потому что не будет родителя сообщение. Поэтому мы отправим уведомление, в котором заголовки электронной почты будут содержать только Message-ID: . Давайте представим электронное письмо с этим:
Следующее уведомление в теме должно иметь References: поле, содержащее Message-ID предыдущего сообщения в этой теме.
В документации RFC упоминается, что некоторые реализации могут использовать References: поле для отображения «треда обсуждения». Из приведенных выше примеров это становится яснее, что можно пройти назад через поле «References:» чтобы найти родителя каждого сообщения в списке.
Добавление метода, который дает нам содержимое для References: заголовок довольно прост. Мы уже есть метод, который дает нам все остальные обзоры в потоке. Помните, что reviews_in_thread Метод также сортирует отзывы от самых ранних до последних.
Обратите внимание, что мы разделяем идентификаторы сообщений пробелами.
Теперь у нас есть метод для каждого из трех интересующих нас заголовков. их всех вместе, мы добавим метод с очень подходящим названием, который называется headers .
Этот метод можно добавить в приватный раздел нашего класса NotificationMailer. Уведомление что он принимает и проходит по текущему обзору. Он также удаляет любые nil или empty
заголовки с использованием встроенного метода отклонения Ruby.
Мы очень близки, и последнее, что осталось сделать, это добавить вызываемый метод когда мы хотим отправить уведомление.
Шаг 5: Метод `review_notification`
Шаг 6: Отправка электронных писем
Чтобы отправить электронное письмо, нам нужно позвонить почтовику открывает новое окно
. Мы можем использовать deliver_now или deliver_later но цель и реализация асинхронные очереди выходят за рамки этого поста. Поэтому мы будем использовать deliver_now
Обычно мы хотим отправлять электронные письма с контроллера или объекта службы и часто с использование какой-либо службы очередей. Отправка электронного письма будет выглядеть примерно так:
Gmail не использует потоки
Когда мы отправляем электронные письма с помощью этой почтовой программы, мы замечаем, что потоки приложения Apple Mail в совершенстве. Но празднование недолговечно, потому что электронные письма не передаются. Gmail.
Из официального канала/блога Google открывает новое окно
мы узнаем, что если вы получите два электронных письма с одной и той же темой от одного и того же отправителя, эти электронные письма не будут объединены в цепочки, если только одно явно не ссылается на другое (используя References: заголовок).
Похоже, мы придерживаемся этого правила, так что же нам делать дальше?
Подход Github
Возвращаясь к чертежной доске, мы могли бы решить посмотреть, как справляются другие поставщики услуг правильно отправлять электронные письма в этой теме. Одной из таких компаний является Github. Если у тебя есть уведомление в вашем почтовом ящике от Github, то вы заметите, что они сделали очень хорошая работа по обработке писем.
Если вы посмотрите на заголовки нескольких сообщений в ветке Github, вы заметите, что The самое первое письмо в цепочке не имеет In-Reply-To: или Ссылки: поля заголовка. Это содержит только Message-ID: .
Message-ID: <orgname/project/pull/id@github.com>
Эта реализация явно отличается от того, как RFC инструктирует нас устанавливать наши заголовки. для работы с резьбой. Но если этот подход достаточно хорош для Github, то, безусловно, достаточно хорошо для Великих Книг.
Теперь пришло время рефакторинга.
Шаг 1: Добавьте `thread_id`
Чтобы убедиться, что мы все на одной странице, давайте изучим заголовки с Github. электронные письма. Начиная со второго письма, все письма в ветке одинаковые In-Reply-To:
и References: поля. Оба этих поля заголовка относятся к одному и тому же Message-ID . Нет заголовка под названием Thread-Id но мы будем называть это идентификатором сообщения идентификатор потока для удобства поиска.
Идентификатор темы относится к уведомлению о первом отзыве, поэтому мы будем использовать первый отзыв в thread, когда мы создаем идентификатор потока.
Идентификатор нашей темы — это идентификатор сообщения, который относится к первому отзыву в теме. Независимо от того, какой отзыв в треде, который мы просматриваем, идентификатор треда всегда будет одним и тем же. За исключением самый первый отзыв. Уведомление о первом пересмотре не будет иметь In-Reply-To: или References: поле
Помните, что reviews_in_thread вернет пустое отношение, если нет других отзывы в треде. В таком случае first_review будет nil и мы уже убедились что message_id возвращает пустую строку, когда nil отзыв принят.
Шаг 2: Обновите `in_reply_to` и `ссылки`
Оба метода теперь возвращают одно и то же значение. Который в книгах большинства людей является запахом кода. Когда мы смотрим на метод заголовков, мы понимаем, что эти два метода являются «человеком посередине» методы. Таким образом, мы можем обновить метод заголовков следующим образом:
Мы больше не используем in_reply_to или references метод, чтобы мы могли удалить их 🎉.
Шаг 3: Нужен ли нам `Message-ID`?
Вы можете обнаружить, что ваш поставщик услуг электронной почты перезаписывает или игнорирует message_id
что вы предоставляете. Если это ваш случай, то нет смысла предоставлять message_id , поскольку он будет перезаписан. Означает ли это, что мы зря потратили время на это точка?
Хорошая новость в том, что не все потеряно! Нам не нужно передавать идентификатор сообщения для потоковой передачи работать. Пока наш In-Reply-To: и References: поля соответствуют нашим электронным письмам будет резьба.
Теперь мы можем упростить наш класс NotificationMailer. Мы можем удалить message_id заголовок. А теперь headers метод становится.
В первом письме в цепочке не будет References: или In-Reply-To: поля. Но от второе письмо после References: и In-Reply-To: оба поля будут использовать thread_id как их стоимость.
У нас есть очень простой почтовый класс, и у нас есть электронные письма в этой ветке, какой замечательный день. Я конечно, мы можем еще больше оптимизировать этот класс, но пока я оставлю его как есть.
Имеет ли значение тема письма?
Тема письма имеет значение. Отправка электронных писем с последовательным In-Reply-To: и References: поля не будут правильно связаны, если мы не используем одну и ту же строку темы. Документация в Интернете создает впечатление, что все, что нам нужно, это заголовки электронной почты для threading работать, но методом проб и ошибок оказалось иначе.
Таким образом, Great Books будет использовать одну и ту же строку темы для всех электронных писем, принадлежащих одной и той же группе. нить.
(Я предполагаю, что вы читали первую часть этой серии – если нет, идите и сделайте это
– и изучили необработанный текст хотя бы одного сообщения электронной почты.)
Теперь, когда вы увидели эту мешанину полуудобочитаемого извержения, с помощью которой открывается типичное сообщение электронной почты, давайте углубимся в детали. Мы собираемся начать с самого минимума — заголовков, необходимых для каждого стандартного сообщения электронной почты в Интернете:
От: Уэс Морган Дата: Пн, 9 июля 2012 г. 19:12:28 -04:00
Да, это так. Если вы посмотрите на RFC 5322 (в частности, раздел 3.6, таблица на стр. 20), вы увидите, что только эти два заголовка ДОЛЖНЫ появляться в обычном интернет-сообщении. (Читая RFC, вы по-новому оцените различия между ДОЛЖЕН, СЛЕДУЕТ, НЕ ДОЛЖЕН, НЕ ДОЛЖЕН и т. д. Не зря эти термины пишутся заглавными буквами.) Таким образом, вполне возможно, что вы можете получить сообщение, в котором нет ничего, кроме заголовков From и Date; расслабься, это “законно”.
Заголовок Date изменился за последние годы, особенно в том, что касается информации о часовом поясе. Старые стандарты допускали сокращения, такие как EST для восточного стандартного времени; сегодня стандарт требует 4-значного числового смещения от универсального координированного времени (UTC) с префиксом + или – по мере необходимости. Итак, в приведенном выше примере указано смещение -4 часа от UTC; это восточное летнее время в США. Следует также отметить, что день недели и секунды не являются обязательными; между этим и тем фактом, что большинство почтовых агентов также любезно принимают заголовки в старом стиле, вы можете увидеть некоторое разнообразие заголовков Date:. (ВАЖНОЕ ПРИМЕЧАНИЕ: это НЕ дата/время доставки сообщения, а скорее дата/время, когда отправитель привел сообщение в его окончательную форму, другими словами, когда он нажал «Отправить».)
Теперь, когда мы рассмотрели два обязательных заголовка, давайте поговорим о тех, которые, если они появляются, должны появляться только один раз в данном сообщении электронной почты. Начнем с очевидного:
Кому: Уэс Морган Копия: , Тема: RE: проверка необычного текста имени в заголовках Идентификатор сообщения:
Самые зоркие среди вас, вероятно, думают: «Подождите секунду, а где заголовок скрытой копии?» Что ж, ответ прост. Скрытая копия означает «слепая копия», поэтому, несмотря на то, что этот заголовок передается между агентами пересылки почты по мере необходимости, он удаляется (если присутствует) до того, как сообщение будет помещено в ваш почтовый ящик. (Если вам действительно интересно, запустите сетевой анализатор (например, Wireshark) для незашифрованного SMTP-сервиса; вы, вероятно, поймаете несколько заголовков скрытой копии в потоке данных.)
Итак, что осталось? Что ж, если вы отправляете (или получаете) ответ на более раннее сообщение электронной почты, в ответе появляется еще несколько заголовков:
В ответе: Ссылки:
В ответе: Ссылки:
От: XXX Дата: Пн, 10 мая 2010 г. 23:20:59 +0200 Идентификатор сообщения:
(Обратите внимание, что этот Message-ID не находится в заголовке «Ссылки», потому что никто еще не сослался на это сообщение с ответом!)
Сюрприз – вы только что узнали, как работают почтовые клиенты “потокового обсуждения”. По сути, они могут просмотреть любое сообщение в цепочке, взять его заголовок «Ссылки» и найти другие сообщения в вашем почтовом ящике.
Иногда кто-то хочет направить ответы на адрес, отличный от указанного в заголовке From. Хотя это может использоваться отдельными лицами (если это позволяет их почтовый клиент), мы чаще всего видим это в сочетании со списками рассылки. Таким образом, у нас есть заголовки Reply-To, подобные этому:
Кому ответ: bighuge-list@listhostsite.org
Наконец, есть заголовок «один и только один раз», который иногда появляется в ваших почтовых сообщениях:
Отправитель: Уэс Морган
Этот должен отображаться только в том случае, если/когда отправитель сообщения НЕ согласен с адресом, указанным в заголовке From; другими словами, кто-то/что-то отправляет сообщение от имени оригинального автора. Например, вы часто будете видеть это в сообщениях списка рассылки, например:
От: Уэс Морган Отправитель: Большой огромный список рассылки
Итак, резюмируя:
Каждое сообщение должно включать заголовки Date и From.
Кому, Копия, Тема и Идентификатор сообщения НЕ требуются RFC.
Заголовки скрытой копии существуют, но только «в пути» — они удаляются до того, как сообщение попадает в ваш почтовый ящик.
Наличие заголовков In-Reply-To и References указывает на то, что сообщение является ответом на предыдущее сообщение.
Заголовок «Ссылки» делает возможным «потоковое чтение почты» и архивирование обсуждений.
Заголовок «Ссылки» будет увеличиваться в размере с каждым ответом в серии сообщений.
Заголовок Sender обычно указывает, что сообщение доставляется одним лицом/стороной от имени другого, как видно из списка рассылки или делегированных полномочий.
Reply-To направляет ответы на адрес, отличный от указанного в заголовке From.
Если вы видите более одного экземпляра любого из этих заголовков в одном сообщении электронной почты, происходит что-то глупое.
