- From sent to cc что значит
- OpenRate.us
- Сайт про CRM-маркетинг, рассылки и вот это всё
- Разбираемся со служебными заголовками электронной почты
- X-заголовки
- Разбираемся со служебными заголовками электронной почты : 1 комментарий
- Что такое Cc и Bcc, и как их использовать при поддержке клиентов?
- Типы получателей письма
- Примеры использования копий
- Как мы реализовали поддержку копий?
- Базовая функциональность
- Полезные фишки
From sent to cc что значит
Минимально необходимыми являются следующие поля «Date:«, »From:«, »Cc:» и/или «To:«, например:
Date: Fri, 6 Dec 2002 23:26:50 +0300 (MSK/MSD)
Date: Fri, 6 Dec 2002 23:26:50 +0300 (MSK/MSD)
Date: Fri, 6 Dec 2002 23:26:50 +0300 (MSK/MSD)
где «Date:«, »From:«, »Cc:» и «To:» являются именами заголовка, а через пробел напротив каждого имени заголовка указано соответствующее содержание. Определим значение каждого указанного имени заголовка:
From: — указывает адрес отправителя (в примере мы видим, что письмо было отправлено с адреса vasya@domain.ru);
To: — адрес(а) получателя(ей) (получателем в нашем примере является ivan@domain.com). Отметим, что поле «To:» не обязано содержать адрес получателя, а также может содержать адреса нескольких получателей;
Cc: (Carbon Copy) — адресация копий, этот заголовок является расширением поля «To», он указывает дополнительных получателей письма (получатель «To» видит список всех «Cc»). Различий между заголовками «To» и «Cc», в сущности, нет, если не считать, что некоторые почтовые программы рассматривают их по-разному, генерируя ответ на сообщение. В примере № 1 поля Cc нет, то есть письмо было отправлено единственному получателю ivan@domain.com. Из примера № 2 видно, что данный заголовок принадлежит адресату ivan@domain.com, которому отправлена копия письма (он не видит поле To). Пример № 3 показывает, что письмо было отправлено получателю письма ivan@domain.com, а также копия письма была отправлена на ящик ivan@domain.net.
Но это только самые основные поля заголовка. Обычно заголовок содержит значительно больше полей, чем указано выше. Давайте с ними ознакомимся.
Message-Id: — уникальный идентификатор письма, присваиваемый каждому сообщению, — чаще всего первым почтовым сервером, который встретится у него на пути, либо же почтовым клиентом. Обычно он имеет форму «abrakadabra@domain.ru, где «abrakadabra» набор произвольных символов, а вторая часть «domain.ru» — имя машины, присвоившей идентификатор. Иногда, но редко, «abrakadabra» включает в себя имя отправителя. Message-Id используется программами доставки почты во избежание «зацикливания» письма;
Subject: — тема письма (наличие Re: означает ответ; Fwd: — переадресацию). Почтовый стандарт допускает наличие только латинских символов (US-ASCII) в поле «Subject» поэтому, несмотря на то, что многие пользователи заполняют данное поле по-русски, этого делать не рекомендуется. Нормальная ситуация — когда написанная по-русски тема письма при отправке перекодируется почтовой программой отправителя в 7-битную base64 с указанием языковой кодировки, в которой эта тема написана (как это делают программы Pine, Pegasus Mail), а почтовая программа получателя декодирует тему письма в читаемый вид. Однако это возможность почтового стандарта MIME, который программа UUPC не поддерживает;
Reply-To: — адрес для ответов. Несмотря на то, что этот заголовок имеет множество способов цивилизованного применения, он также используется спамерами для отведения удара от себя. Может быть, какой-нибудь наивный спамер и захочет собирать ответы на свои письма и укажет верный заголовок «Reply-to:», но большинство указывает там либо несуществующий адрес, либо адрес невинной жертвы;
In-Reply-To: — показывает, что сообщение относится к типу «ответ на ответ»;
Comments: — означает комментарий. Этот заголовок не является стандартным, а потому может содержать любую информацию. Подобные заголовки добавляются некоторыми почтовыми программами (в частности, популярной программой Pegasus) для идентификации отправителя, но часто прописывается вручную спамерами, так что относиться к нему следует с осторожностью;
Status: — статус письма (новое, прочитанное);
Apparently-To: — эти заголовки нетипичны для нормальных сообщений, они обычно являются признаком массовой рассылки. В последнее время для массовых рассылок используется программное обеспечение, достаточно «умное», чтобы не плодить гигантские списки из этих заголовков;
Organization: — абсолютно свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети. Отправитель, как правило, контролирует этот заголовок, поэтому там вполне может быть что-то вроде ЗАО «Рога и Копыта»;
Priority: — исключительно свободный заголовок, устанавливающий приоритет сообщения. Большинство программ его игнорируют. Часто используется спамерами в форме «Priority: urgent» (или что-нибудь в этом роде) с целью привлечения внимания к сообщению;
Errors-To: — указывает адрес для отсылки автоматически генерируемых сообщений об ошибке, таких как «нет такого пользователя». Это редко используемый заголовок, так как большинство отправителей обычно хотят получать сообщения об ошибках на исходящий адрес, который используется почтовыми серверами по умолчанию.
Источник
OpenRate.us
Сайт про CRM-маркетинг, рассылки и вот это всё
Разбираемся со служебными заголовками электронной почты
Чтобы разобраться в том, почему письмо письмо попадает в спам или отследить, кто его прислал, загляните в служебные заголовки.
Где найти служебные заголовки email в интерфейсах Mail.Ru, Яндекс.Почте и Gmail, смотрите здесь.
Стандартные служебные заголовки электоронной почты
Cc: — Carbon Copy — заголовок является расширением поля «To:», он указывает дополнительных получателей письма. Некоторые почтовые программы рассматривают «To:» и «Cc:» по-разному, генерируя ответ на сообщение.
Content-Transfer-Encoding: — MIME-заголовок, не имеет отношения к доставке почты, отвечает за то, как программа-получатель интерпретирует содержимое сообщения.
MIME — стандартному метод помещения в письмо нетекстовой информации (см. в Википедии).
Content-Type: — MIME-заголовок, сообщающий почтовой программе о типе данных, хранящихся в сообщении.
Date: — дата создания сообщения. Не стоит принимать на веру из-за возможности подделки или ошибки во времени у отправителя.
Errors-To: — адрес для отсылки автоматических сообщений об ошибках. Большинство отправителей обычно хотят получать сообщения об ошибках на исходящий адрес, который используется почтовыми серверами по умолчанию.
From (без двоеточия) — конвертный заголовок «From» формируется на базе информации, полученной от команды MAIL FROM. Например, если отправляющая машина говорит MAIL FROM: 123@123.com, получающая машина сгенерирует строчку следующего вида: «From 123@123.com»
! Конвертный заголовок создается не отправителем сообщения, а компьютером, через который прошло это сообщение.
From: (с двоеточием) информация об адресе отправителя, указанная самим отправителем.
Message-Id: — более или менее уникальный идентификатор, присваиваемый каждому сообщению, чаще всего первым почтовым сервером, который встретится у него на пути. Обычно он имеет форму «blablabla@domen.ru», где «blablabla» может быть абсолютно чем угодно, а вторая часть — имя машины, присвоившей идентификатор. Иногда, но редко, «blablabla» включает в себя имя отправителя.
Если структура идентификатора нарушена (пустая строка, нет знака @) или вторая часть идентификатора не является реальным интернет-сайтом, значит письмо — вероятная подделка.
Также Message-id: или Message-ID:.
In-Reply-To: — заголовок Usenet, который иногда появляется и в письмах. «In-Reply-To:» указывает идентификатор некоего сообщения, на которое данное сообщение является ответом. Этот заголовок нетипичен для писем, если только письмо действительно не является ответом на сообщение в Usenet. Спаммеры иногда им пользуются, возможно, чтобы обойти фильтрующие программы.
Mime-Version: или MIME-Version: — MIME-заголовок, обозначающий версию MIME-протокола, который использовался отправителем.
Organization: — свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети.
Priority: — свободный заголовок, устанавливающий приоритет сообщения. Большинство программ его игнорируют. Часто используется спаммерами в форме «Priority: urgent» с целью привлечения внимания к сообщению.
Received: — содержит информацию о прохождении письма через почтовый сервер. Анализируя заголовок «Received:», мы видим, кто его отправил и какой путь оно проделало, попав в наш ящик.
Reply-To: — указывает адрес, на который следует посылать ответы. Несмотря на то, что этот заголовок имеет множество способов цивилизованного применения, он также используется спаммерами для отведения гневных ответов получателей спама от себя.
Return-Path: — адрес возврата в случае неудачи, когда невозможно доставить письмо по адресу назначения. Обычно совпадает с MAIL FROM. Но может и отличаться.
Subject: — тема сообщения.
To: — адрес получателя (или адреса). При этом поле «To:» может не содержать адреса получателя, так как прохождение письма базируется на конвертном заголовке «To», а не на заголовке сообщения «To:».
X-заголовки
Это отдельный набор заголовков, начинающихся с заглавной X с последующим дефисом. Существует договоренность, согласно который X-заголовки являются нестандартными и добавляются только для дополнительной информации. Поэтому нестандартный информативный заголовок должен иметь имя, начинающееся на «X-«. Эта договоренность, однако, часто нарушается.
X-Confirm-Reading-To: — заголовок запрашивает автоматическое подтверждение того, что письмо было получено или прочитано. Предполагается соответствующая реакция почтовой программы, но обычно он игнорируется.
X-Errors-To: — заголовок указывает адрес, на который следует отсылать сообщения об ошибках. Он реже соблюдается почтовыми серверами.
X-Mailer: или X-mailer: — свободное поле, в котором почтовая программа, с помощью которой было создано данное сообщение, идентифицирует себя (в рекламных или подобных целях). Поскольку спам часто рассылается специальными почтовыми программами, это поле может служить ориентиром для фильтров.
X-Priority: — еще одно поле для приоритета сообщения.
X-Sender: — почтовый аналог Usenet-заголовка «Sender:». Предполагалось, что он будет доставлять более надежную информацию об отправителе, чем поле «From:», однако в действительности его так же легко подделать.
X-UIDL: — уникальный идентификатор, используемый в POP-протоколе при получении сообщений с сервера. Обычно он добавляется между почтовым сервером получателя и собственно почтовой программой получателя. Если письмо пришло на почтовый сервер уже с заголовком «X-UIDL:», это скорее всего спам — очевидной выгоды в использовании заголовка нет, но спаммеры иногда его добавляют.
Еще служебные заголовки
List-Unsubscribe: — читайте здесь.
X-Mras: служебный заголовок Mail.Ru, фиксирующий наличие или отсутствие спама в письме на основе разработанной в Mail.Ru системы фильтрации спама — MRAS (Mail.Ru Anti-Spam).
List-id: — служебный заголовок для сбора статистики по отдельным письмам в Почтовом офисе Яндекса.
X-Mailru-Msgtype: — аналогичный «List-id:» заголовок для Postmaster@Mail.Ru.
X-PMFLAGS: и X-Distribution: — специфические заголовки программы Pegasus Mail.
Sender: — нетипичен для писем (обычно используется «X-Sender:»), иногда появляется в копиях Usenet-сообщений. Предполагает идентификацию отправителя, в случае с Usenet-сообщениями является более надежным, чем строчка «From:».
Comments: — заголовок не является стандартным, может содержать любую информацию. Чаще всего используется в виде «Comments: Authenticated sender is ».
References: — редко используется в почтовых сообщениях, за исключением копий Usenet-сообщений. Он используется в Usenet для прослеживания «дерева ответов», к которому принадлежит сообщение. Если он появился в письме, то это письмо является копией Usenet-сообщения или почтовый ответ на Usenet-сообщения.
Newsgroups: — используется в письмах, связанных с Usenet: либо в копии отправленного в Usenet сообщения, или в ответе на эти сообщения. В первом случае он указывает конференцию, в которые сообщение было послано, а во втором — конференции, в которые было послано сообщение, на которое данное письмо является ответом.
Apparently-To: — сообщения с большим количеством получателей иногда имеют длинный список заголовков вида «Apparently-To: 123@domen.ru» (по одной строчке на получателя). Эти заголовки нетипичны для нормальных сообщений, они обычно являются признаком массовой рассылки.
Bcc: — Blind Carbon Copy, слепая копия. Если вы видите этот заголовок в полученном сообщении, значит, «что-то пошло не так». Этот заголовок используется так же, как и «Cc:», но не должен появляться в списке заголовков.
Префикс Resent- может быть добавлен при пересылке письма. Например, «Resent-From:» или «Resent-To:». Такие поля содержат информацию, добавленную тем, кто переслал сообщение:
Поле «From:» содержит адрес первоначального отправителя.
«Resent-From:» — адрес переславшего.
Представление заголовков письма в наглядном формате с помощью гугловского приложения.
Большая часть заголовков взята в статье на antispam.ru. Почитайте, там интересно.
Разбираемся со служебными заголовками электронной почты : 1 комментарий
Спасибо за статью! А есть информация, как можно добавить заголовки для постмастера/постофиса в Mailchimp?
Источник
Что такое Cc и Bcc, и как их использовать при поддержке клиентов?
Если вы активно используете почту при общении с клиентами и коллегами, редкий день обходится без копий. Они являются неотъемлемой частью рабочей переписки. Поэтому многие клиенты, перебираясь на Омнидеск со старой доброй почты, часто спрашивали о поддержке Cc и Bcc. До появления этой функциональности мы получили 47 (!) просьб добавить её. Цифра внушительная, ведь о своих потребностях и вопросах в лучшем случае пишут 5-7% желающих.
Перед тем, как перейти к подробностям нашей реализации копий, давайте разберёмся, что они собой представляют.
Типы получателей письма
To: (кому) — основной получатель письма.
Cc: (копия, carbon copy) — вторичные получатели письма, которым направляется копия. Они видят и знают о наличии друг друга.
Bcc: (скрытая копия, blind carbon copy) — скрытые получатели письма, чьи адреса не показываются другим получателям.
Примеры использования копий
а. Пользователь обратился за помощью и попросил отправлять ответы как на рабочую, так и личную почту. Вы указываете его личный адрес в копии (Cc), чтобы он смог отвечать с любого адреса и в каждом из них видеть всю переписку.
б. Клиент оплатил консалтинг/поддержку/разработку, и вы регулярно общаетесь с его сотрудниками. Вы добавляете его в копию (Cc), чтобы он получал все ваши ответы, мог в любой момент вклиниться в переписку и оценить качество предоставляемых вами услуг.
в. Руководитель хочет следить за общением поддержки с VIP-клиентами. В обращениях от этих клиентов руководитель добавляется в скрытую копию (Bcc), чтобы он всегда получал ваши ответы (с историей переписки).
Прелесть в том, что клиент не знает о «слежке», а руководитель может ответить лично вам и, к примеру, сделать замечание 🙂
г. Клиент обращается к вам, чтобы обсудить получение скидки и способы оплаты. Он сразу добавляет своего бухгалтера в копию (Cc), чтобы тот мог следить за ходом общения и принять эстафету в нужный момент.
Как мы реализовали поддержку копий?
Приведённые выше примеры описывают лишь некоторые сценарии, которые клиенты «продавали» нам, аргументируя необходимость поддержки копий на сервисе. Мы реализовали все стандартные моменты, но не забыли добавить и несколько полезных фишек. Рассмотрим всё по порядку.
Базовая функциональность
1) Справа от названия поля «Получатель» мы разместили две ссылки для добавления копий — «Сс» и «Bcc».
2) При нажатии на «Cc» появляется поле «Копия», и пропадает ссылка «Cc».
3) При нажатии на «Bcc» появляется поле «Скрытая копия», и пропадает ссылка «Bcc».
4) Если нажать на ссылку «убрать», то поле пропадает, а ссылка «Сс»/«Всс» возвращается на своё место (справа от названия поля «Получатель»).
5) Когда сотрудник добавляет адрес в обычную копию (Cc), его ответ отправляется на основной адрес из поля «Получатель» и на адрес из поля «Копия». В этом случае оба пользователя видят, что письмо было доставлено на два адреса. Каждый из них может ответить как сотруднику, так и сотруднику + другому пользователю.
6) Когда сотрудник добавляет адрес в скрытую копию (Bcc), его ответ отправляется на основной адрес из поля «Получатель» и на адрес из поля «Скрытая копия». В этом случае основной пользователь видит, что письмо пришло только ему, поэтому его ответ может быть отправлен только сотруднику.
При этом пользователь из скрытой копии видит, кто был основным получателем, и может отправить письмо как сотруднику, так и сотруднику + основному получателю.
7) Поддержка копий работает и в обратном направлении. Если пользователь отправляет запрос (или новый ответ в текущую переписку) и добавляет другой адрес в Cc, мы автоматически прописываем этот адрес в поле «Копия», чтобы при ответе сотрудника письмо отправлялось на оба адреса.
Полезные фишки
8) Все изменения в полях «Получатель», «Копия» и «Скрытая копия» фиксируются в истории действий.
9) Для каждого обращения мы запоминаем все адреса, которые указывались в полях «Получатель», «Копия» и «Скрытая копия». Поэтому после удаления адреса из поля его можно легко вернуть. Достаточно кликнуть в нужном поле, и мы предложим выбрать адрес из выпадающего списка.
10) Когда пользователь из скрытой копии отвечает сотруднику и основному пользователю, его письмо добавляется в обращение в виде обычного ответа. Если же он отвечает только сотруднику, тогда его письмо добавляется в обращение в качестве заметки, которая не видна основному пользователю (при просмотре переписки по обращению в своём аккаунте).
11) В правилах для входящих обращений мы добавили условие «Копия (Cc) обращения», чтобы можно было отслеживать наличие определённого адреса (или домена) в копии и автоматически выполнять нужные действия.
12) Во всех типах правил появились два новых действия — «Добавить в копию» и «Добавить в скрытую копию» на случай, если требуется добавить адреса в копии, когда обращение соответствует условиям правила.
Вот такие полезные копии. Если вы раньше не использовали их, теперь обязательно начнёте 🙂
Источник