Bcc recipients что это
Bcc recipients что это
Компании, которые активно используют почту при общении с клиентами, и дня не могут прожить без копий. Это неотъемлемая часть их рабочего процесса. Поэтому многие клиенты, перебираясь на Омнидеск со старой доброй почты, первым делом спрашивали о поддержке Cc и Bcc. До появления этой функциональности мы получили 47 (!) просьб добавить её. Цифра внушительная, ведь о своих потребностях и вопросах в лучшем случае пишут 5-7% желающих.
Перед тем как перейти к подробностям нашей реализации копий, давайте разберёмся, что они собой представляют.
To: (кому) — основной получатель письма.
Cc: (копия, carbon copy) — вторичные получатели письма, которым направляется копия. Они видят и знают о наличии друг друга.
Bcc: (скрытая копия, blind carbon copy) — скрытые получатели письма, чьи адреса не показываются другим получателям.
а. Пользователь обратился за помощью и попросил отправлять ответы как на рабочую, так и личную почту. Вы указываете его личный адрес в копии (Cc), чтобы он смог отвечать с любого адреса и в каждом из них видеть всю переписку.
б. Клиент оплатил консалтинг/поддержку/разработку, и вы регулярно общаетесь с его сотрудниками. Вы добавляете его в копию (Cc), чтобы он получал все ваши ответы, мог в любой момент вклиниться в переписку и оценить качество предоставляемых вами услуг.
в. Руководитель хочет следить за общением поддержки с VIP-клиентами. В обращениях от этих клиентов руководитель добавляется в скрытую копию (Bcc), чтобы он всегда получал ваши ответы (с историей переписки).
Прелесть в том, что клиент не знает о «слежке», а руководитель может ответить лично вам и, к примеру, сделать замечание 🙂
г. Клиент обращается к вам, чтобы обсудить получение скидки и способы оплаты. Он сразу добавляет своего бухгалтера в копию (Cc), чтобы тот мог следить за ходом общения и принять эстафету в нужный момент.
4) Чтобы добавить адрес в поле, нужно указать его целиком и нажать на Enter. В итоге он преобразовывается в своего рода метку (см. предыдущие скриншоты).
5) В копиях можно прописывать несколько получателей. Ограничений мы не ставили, но не пытайтесь таким образом делать «массовую» рассылку 🙂
6) Если нажать на ссылку «убрать», то поле пропадает, а ссылка «Сс»/«Всс» возвращается на своё место (справа от названия поля «Получатель»).
7) Когда сотрудник добавляет адрес в обычную копию (Cc), его ответ отправляется на основной адрес из поля «Получатель» и на адрес из поля «Копия». В этом случае оба пользователя видят, что письмо было доставлено на два адреса. Каждый из них может ответить как сотруднику, так и сотруднику + другому пользователю.
8) Когда сотрудник добавляет адрес в скрытую копию (Bcc), его ответ отправляется на основной адрес из поля «Получатель» и на адрес из поля «Скрытая копия». В этом случае основной пользователь видит, что письмо пришло только ему, поэтому его ответ может быть отправлен только сотруднику.
При этом пользователь из скрытой копии видит, кто был основным получателем, и может отправить письмо как сотруднику, так и сотруднику + основному получателю.
9) Возможность использовать обычную и скрытую копии появилась также на странице создания обращения сотрудником.
10) Поддержка копий работает и в обратном направлении. Если пользователь отправляет запрос (или новый ответ в текущую переписку) и добавляет другой адрес в Cc, мы автоматически прописываем этот адрес в поле «Копия», чтобы при ответе сотрудника письмо отправлялось на оба адреса.
Контроль переписки в Postfix («большой брат» следит за тобой)
Таблицы соответствия отправителя/получателя с адресами доставки копий сообщений (функция доступна в Postfix 2.1 и выше.) То что нам и нужно.
Способ с использованием индексированных hash карт
Для примера рассмотрим вариант копирования исходящих сообщений:
2. Добавляем в main.cf строчку
3. Обязательно создаем индексированный файл:
4. Перезагружаем постфикс и любуемся копированием исходящей почты.
Аналогичные шаги нужно проделать для получения возможности копирования входящей почты. Вместо sender_bcc_maps следует использовать recipient_bcc_maps.
Внимание! После внесения изменений не забываем перестроить хэш:
Способ с использованием MySQL
Подразумевается, что вы уже используете MySQL совместно с Postfix для хранения учетных записей, транспорта и т.д.
1. Создаем табличку bcc в вашей базе данных
2. в /usr/local/etc/postfix/ создаем файлы sender_bcc.cf и recipient_bcc.cf:
3. В main.cf добавляем строчки
4. Перезапускам Postfix для применения изменений. Изменения данных в таблице MySQL bcc применяются без перезапуска Postfix.
Избавляемся от дублирования сообщений bcc_maps
Чтобы не происходило дублирования почты при использовании bcc_maps в master.cf следует добавить строчку:
В моём случае это выглядит так:
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Комментариев: 15
Большой брат всегда следит за тобой 🙂
Ммм.. Спасибо автору.. То что доктор прописал =)
Спасибо автор, нужная вещь как раз искал реализацию!
Только есть еще вопрос «Избавляемся от дублирования сообщений bcc_maps» это нужно прописывать для всех вариантов или только тем кто юзает MySQL
попробовал настроить пересылку исходящих писем посредством hash. Возник вопрос:
Значит, то что доктор прописал(2 способ), создаём табличку, и всё хорошо, тогда стоит немного подумать, 1. чтобы всё в кучу не валить, нам необходимо для каждого пользователя создать ящик backup, прописать его в 2 таблицы, в этом случае у нас все входящие-исходящие для данного письма будут валится в одну папку на сервере, свалочка получится, по хорошему для каждого пользователя надо будет создать дополнительно 2 почтовых ящика, user_backup_from и user_backup_to.. Нехорошо получается, геморно это, может кто расскажет, как будут ходить письма внутри домена? одно и то же письмо будет сохранено 2 раза? как то опять нехорошо. Может валить всё в кучу, отправлять логи postfix в mysql, потом на это всё хозяйство натянуть веб морду с возможностью выгрузки файлов в отдельный каталог по отдельному пользователю, зато ни таблиц, ни лишнего мусора и всегда удобно подглядеть, восстановить
А есть ли возможность делать исключения?
Т.е. чтобы делались бекапы всей исходящей почты домена, кроме 2 ящиков.
Подскажите а как может произойти дублирование, которое вы лечите редактированием master.cf?
спасибо огромной за отключение дублирования
Потратил целый день на буржуйских форумах на решение проблемы с дублированием. Нигде ни слова про опцию, только вопросы как убрать дублирование и ни одного ответа!
еще немного докрутил свой сервер до того чего хочется
жаль только не получается через MySQL организовать пересылку скажем входящих от одного пользователя нскольким а не одному
Скажите есть ли возможность и как это реализовать. Допустим чтоб если письмо от pupkin@mail.ru пришло на andrey@mydomen.ru, то только тогда копия письма приходит большому брату.
Я так понял что вы хотите сделать копирование писем определенного отправителя на ящик одного из ваших пользователей. Можно конечно попробовать добавить этого отправителя в sender_bcc: pupkin@mail.ru backup@mydomain.ru
Не знаю правда будет такое работать или нет, сейчас нет возможности проверить. но даже чисто теоретически это правило всё равно распространяется на всех пользователей вне зависимости кому отправлено сообщение, а не на кого-то конкретно. Возможно в новой версии postfix это как-то реализовано, нужно читать документацию.
Последние версии PostfixAdmin поддерживают добавление адресов, на которые будет копироваться почта, однако письма приходят в двух экземплярах. После добавления:
все работает, как положено!
Копии всех отправленных
Эта заметка имеет характер исследования. Все упомянутые в заметке эксперименты проводились на ОС Debian. Пожалуйста не используйте слепое копирование примеров. Автор не гарантирует, что применение изложенной здесь информации не приведет к потере данных.
Содержание
Кто обычно сохраняет письмо в «Отправленные»
Чаще всего это делает MUA. Отправляя письмо, он выполняет две операции: отправляет письмо через SMTP + сохраняет копию в «Отправленные» (на сервере, если используется IMAP, либо только на удаленном клиенте, при использовании SMTP/POP). Если же письмо через SMTP отправляет, например сайт или спамер/хакер подключившийся посредством telnet и как-то узнавший пароль, либо заливший вредоносный скрипт на сервер, то контроль за отправленными письмами полностью теряется. Тем не менее можно организовать контроль всех отправляемых писем (включая письма от несуществующего в базе PostfixAdmin отправителя) и доставку копий всех отправленных в соответствующие ящики.
Как можно организовать контроль всех отправленных
Есть несколько вариантов решения проблемы.
Но в этом случае теряется контроль за отправленными письмами учтенных (в базе PostfixAdmin) системных пользователей, если зарегистрированные пользователи все-таки будут отправлять письма из удаленных MUA без IMAP (такие письма будут оставаться неучтенными за пределами сервера).
Именно четвертый вариант будет подробнее рассмотрен в следующих разделах.
Также будет рассмотрено использование Sieve в Dovecot для перенаправления копий отправленных из «Входящие» в «Отправленные», а также для избежания дублирования отправленных, сохраняемых MUA через IMAP.
См. также заметку с детальным описанием настройки конкретной, рассматриваемой в этой серии заметок, конфигурации:
BCC копии всех писем, отправленных из родных доменов
Итак, задачу полного контроля над отправленными письмами можно решить двумя запросами:
В таком варианте, все входящие извне письма с «чужими» отправителями будут игнорироваться и авто-BCC срабатывать не будет.
query = SELECT username FROM mailbox WHERE username=’%s’ AND active = ‘1’
Будут сохранены не только письма, отправленные не зарегистрированными в PostfixAdmin системными пользователями, но и письма активированных зарегистрированных пользователей, отправленные удаленными MUA (через родной MTA), или отправленные другими способами (например сгенерированные сайтом.)
Тестирование с использованием postmap
Предположим, что:
— зарегистрированный активный ящик,
— еще один зарегистрированный активный ящик,
— незарегистрированный или неактивный ящик,
— родной домен,
— чужой ящик чужого домена.
Используем примеры из предыдущего раздела для проверки SQL-запросов через консоль (показан ввод и вывод).
Зарегистрированный ящик в родном домене.
Должно вернуть имя зарегистрированного ящика в первом же запросе:
Незарегистрированный ящик в родном домене.
Нет значения для незарегистрированного ящика (родного домена) в первом запросе:
Но есть значение для незарегистрированного ящика (родного домена) во втором запросе
Чужой ящик чужого домена.
Нет значения для неизвестного ящика (чужого домена) в первом запросе:
Нет значения для неизвестного ящика (чужого домена) во втором запросе
Копия письма не будет отправлена.
Еще один экзотический пример
Для этого понадобится указать новый файл, описывающий запрос
А сам файл запроса сделать, например, таким
В этом случае будет выполняться всегда только один запрос.
Возможные проблемы
Эксперименты показали, что любые *_bcc_maps применимы только глобально (в файле «main.cf»). Любые попытки использовать их избирательно для отдельных сервисов «master.cf» ни к чему не приводят.
Стоит также помнить о том, что указанный избирательно для какого-нибудь отдельного сервиса в «master.cf», параметр или глобально в «main.cf» () отключает авто-BCC (избирательно или глобально). Кроме этого, он отключает алиасы, и многое другое, что может сломать весь механизм обработки почты (например автоответчики PostfixAdmin).
Перенаправление BCC-копий в «Отправленные» с использованием Sieve
С помощью Sieve, во входящих письмах проверяется отправитель и, если он совпадает с владельцем ящика, то письмо, минуя «Входящие», перенаправляется в «Отправленные».
Конфиг может быть примерно таким
А сам скрипт таким:
Это можно изменить, если помечать авто-BCC в Postfix (см. следующий способ).
Итак, для того, чтобы перемещать из «Входящие» в «Отправленные» только авто-BCC письма, оставляя нетронутыми в папке «Входящие» письма самому себе, нужно будет переделать SQL-запрос Postfix, упомянутый в разделе BCC копии всех писем, отправленных из родных доменов, видоизменив адрес доставки BCC, и добавить распознавание этого изменения в Dovecot.
Изменим первый запрос в Postfix (авто-BCC для зарегистрированных пользователей)
query = SELECT CONCAT(‘%u’, ‘+autobcc’, ‘@’, ‘%d’) FROM mailbox WHERE username=’%s’ AND active = ‘1’
Цветом отмечено отличие от примера из раздела выше.
Подправим конфиг Postfix
Также изменим конфиг Dovecot для Sieve
Как избавиться от дубликатов писем в папке «Отправленные»
Удаление входящих дубликатов с помощью Sieve, в момент доставки
И переделаем скрипт из примера выше, добавив в него отслеживание дубликатов (добавленное выделено цветом ).
Повторная отправка сохраненных IMAP отправленных через LDA
Установим сам incron:
Добавим «root» в список разрешенных.
Все аргументы, передаваемые в скрипт:
Создадим сам shell-скрипт
Скрипт Sieve, обрабатывающий каждое письмо (для incron), попадающее в «Отправленные», может быть таким
Конфиг LDA может быть таким (все остальное можно закомментировать)
В этой схеме есть побочный эффект. Письма, перемещенные в папку «Отправленные» (например просто мышью в MUA), будут перенаправлены на повторную доставку и просто попадут во «Входящие». Поскольку они скорее всего не удовлетворяют условиям проверяющего дубликаты скрипта для входящих, то будут им проигнорированы. Кроме того, если переместить в «Отправленные», например 1000 писем сразу, то наверное это будет не очень хорошая идея.
См. также заметку с детальным описанием настройки конкретной, рассматриваемой в этой серии заметок, конфигурации:
Источники
Источники информации и ссылки перечислены на отдельной странице, указанной внизу главной страницы темы:
Установка и настройка почтового сервера
Preserve Bcc and expanded distribution group recipients for eDiscovery
In-Place Hold and Litigation Hold allow you to preserve mailbox content to meet regulatory compliance and eDiscovery requirements. Information about recipients directly addressed in the To and Cc fields of a message is included in all messages by default, but your organization may require the ability to search for and reproduce details about all recipients of a message. This includes
Recipients addressed using the Bcc field of a message: Bcc recipients are stored in the message in the sender’s mailbox, but not included in headers of the message delivered to recipients.
Expanded distribution group recipients: Recipients who receive the message because they’re members of a distribution group to which the message was addressed, either in the To, Cc or Bcc fields.
How Bcc recipients and expanded distribution group recipients are preserved
As stated earlier, information about Bcc’ed recipients is stored with the message in the sender’s mailbox. This information is indexed and available to In-Place eDiscovery and Hold.
Information about expanded distribution group recipients is stored with the message after you place a mailbox on In-Place Hold or Litigation Hold. Distribution group membership is determined at the time the message is sent. The expanded recipients list stored with the message is not impacted by changes to membership of the group after the message is sent.
| Information about. | Is stored in. | Is stored by default? | Is accessible to. |
|---|---|---|---|
| To and Cc recipients | Message properties in the sender and recipients’ mailboxes. | Yes | Sender, recipients, and compliance officers |
| Bcc recipients | Message property in the sender’s mailbox. | Yes | Sender and compliance officers |
| Expanded distribution group recipients | Message properties in the sender’s mailbox. | No. Expanded distribution group recipient information is stored after a mailbox is placed on In-Place Hold or Litigation Hold. | Compliance officers |
Searching for messages sent to Bcc and expanded distribution group recipients
When searching for messages sent to a recipient, eDiscovery search results now include messages sent to a distribution group that the recipient is a member of. The following table shows the scenarios where messages sent to Bcc and expanded distribution group recipients are returned in eDiscovery searches.
Scenario 1: John is a member of the US-Sales distribution group. This table shows eDiscovery search results when Bob sends a message to John directly or indirectly via a distribution group.
| When you search Bob’s mailbox for messages sent. | And the message is sent with. | Results include message? |
|---|---|---|
| To:John | John on TO | Yes |
| To:John | US-Sales on TO | Yes |
| To:US-Sales | US-Sales on TO | Yes |
| Cc:John | John on CC | Yes |
| Cc:John | US-Sales on CC | Yes |
| Cc:US-Sales | US-Sales on CC | Yes |
Scenario 2: Bob sends an email to John (To/Cc) and Jack (Bcc directly, or indirectly via a distribution group). The table below shows eDiscovery search results.
| When you search. | For messages sent. | Results include message? | Notes |
|---|---|---|---|
| Bob’s mailbox | To/Cc:John | Yes | Presents an indication that Jack was Bcc’ed. |
| Bob’s mailbox | Bcc:Jack | Yes | Presents an indication that Jack was Bcc’ed. |
| Bob’s mailbox | Bcc:Jack (via distribution group) | Yes | List of members of the Bcc’ed distribution group, expanded when the message was sent, is visible in eDiscovery search preview, export and logs. |
| John’s mailbox | To/Cc:John | Yes | No indication of Bcc recipients. |
| John’s mailbox | Bcc:Jack (directly or via distribution group) | No | Bcc information is not stored in the message delivered to recipients. You must search the sender’s mailbox. |
| Jack’s mailbox | To/Cc:John (directly or via distribution group) | Yes | To/Cc information is included in message delivered to all recipients. |
| Jack’s mailbox | Bcc:Jack (directly or via distribution group) | No | Bcc information is not stored in the message delivered to recipients. You must search the sender’s mailbox. |
Frequently asked questions
Q. When and where is Bcc recipient information stored?
A. Bcc recipient information is preserved by default in the original message in sender’s mailbox. If the Bcc recipient is a distribution group, distribution group membership is only expanded if the sender’s mailbox is on hold.
Q. When and where is the list of expanded distribution group recipients stored?
A. Group membership is expanded at the time the message is sent. The list of expanded distribution group members is stored in the original message in the sender’s mailbox. The sender’s mailbox must be on In-Place Hold or Litigation Hold.
Q. Can the To/Cc recipients see which recipients were Bcc’ed?
A. No. This information is not included in message headers, and isn’t visible to To/Cc recipients. The sender can see the Bcc field stored in the original message stored in their mailbox. Compliance officers can see this information when searching the sender’s mailbox.
Q. How can I ensure expanded distribution group recipients are always preserved?
A. To ensure expanded distribution group members are always preserved with a message, Place all mailboxes on hold.
Q. Which types of groups are supported?
A. Distribution groups, mail-enabled security groups, and dynamic distribution groups are supported.
Q. Is there a limit on the number of distribution group recipients that are expanded and stored in the message?
A. Up to 10,000 members of a distribution group is preserved.
Q. Are nested distribution groups supported?
A. Yes, 25 levels of nested distribution groups are expanded.
Q. Where is the Bcc and expanded distribution group recipient information visible?
A. Bcc and expanded distribution group recipients information is visible to Compliance officers when performing an eDiscovery search. Bcc and expanded distribution group recipients are included in search results copied to a Discovery mailbox or exported to a PST file and in the eDiscovery log included in search results. Bcc recipient information is also available in search preview.
Q. What happens if a member of a distribution group is hidden from the organization’s global address list (GAL)?
A. There’s no impact. If recipients are hidden from the GAL, they’re still included in the list of recipients for the expanded distribution group.