Другими словами, это безопасное предположение, что никто из получателей никогда не увидит электронную почту в BCC? Что если получатель является администратором своего (но не отправителя) почтового сервера и может вносить какие-либо изменения в свой сервер?
6 ответов
Нет. SMTP - это протокол открытого текста , использующий методы хранения и пересылки .
Что это значит:
- Открытый текст: каждый сервер, который передает это сообщение, видит его полностью, включая всю информацию заголовка. Хотя каждый получатель в поле BCC , как правило , получает свою собственную электронную почту (так что сервер отправляет настроенную по электронной почте , где все остальные получатели BCC должны быть раздеты (акцент на должны!), В отличии от CC, где данные сохраняется), что одно электронное письмо все еще хранится в заголовках в виде открытого текста (без шифрования, без обфускации, ничего).
- Хранение и пересылка: электронная почта не обязательно отправляется на почтовый сервер получателя напрямую, но может (и обычно) пересылается через ряд промежуточных почтовых серверов; он сохраняется на каждом (в течение неопределенного периода времени) и затем пересылается на следующий переход (опять же, не обязательно в конечный пункт назначения).
- Учтите, что электронная почта отправляется на несуществующий, полный, заблокированный или иным образом нефункциональный адрес - копия почты вместе с диагностическими данными может оказаться в нескольких местах, причем не все из них обязательно являются почтовыми ящиками ( например, журналы ошибок или почтовый ящик администратора почты )
- (это до того, как ваша электронная почта попадет на почтовые серверы получателя, которые могут хранить ее вечно и с готовностью передать ее всем, кто придет вместе с повесткой в суд, но это немного другая история)
Другими словами, ваше предположение небезопасно. Если вы хотите конфиденциальности и безопасности, используйте цифровые подписи и шифрование, например, GPG; Ванильная электронная почта - неправильный инструмент для такой работы.
Любой агент пересылки почты (MTA), полностью соответствующий RFC 2822 (в частности, раздел 3.6.3, Поля адреса назначения), удалит поле Bcc:
из заголовка перед попыткой доставки, что делает невозможным для слепых получателей определить личности слепых получателей.
Есть пара уловов:
Если вы не контролируете самый первый MTA, на который приходят ваши исходящие письма, вы не можете гарантировать, что программное обеспечение этого MTA будет работать в соответствии с инструкциями RFC 2822.
Тот факт, что электронное письмо от вас получателю, который, возможно, был скопирован вслепую, прошел через один или несколько MTA, может сохраниться в журналах этих MTA.
Вы никогда не должны предполагать, что получатели не узнают о получателе BCC. Я получал, чтобы получатели BCCed нажимали "Ответить всем" в своей почтовой программе и объявляли всем о получении ими ранее писем в ошеломляющем непонимании того, что на самом деле означало "BCCed". Если вам действительно нужно, чтобы оно было конфиденциальным, перешлите сообщение из папки "Отправленные" после отправки его исходным получателям, поэтому единственный другой адрес в заголовках сообщений - ваш.
Тем не менее, даже если вы использовали BCC, пока сервер получателя BCC отделен от исходного получателя, сервер получателя не будет иметь доступа к информации BCC, поскольку она будет удалена (или, скорее всего, никогда не будет включена в тело сообщения) почтовым сервером вашего провайдера.
С другой стороны: SMTP не является ни надежным, ни частным. Некоторые авторы утверждают, что SMTP-цепочки серверов существуют, но в целом SMTP отправляет с вашего компьютера вашему провайдеру, провайдеру-получателю. (и сколько внутренних серверов у них есть) Как правило, ваша почта НЕ будет перенаправляться на сторонний почтовый сервер, и на самом деле такие попытки обычно запрещены по причинам антиспама. (Существуют исключения, так как небольшие провайдеры и домашние сети будут перенаправлять их провайдерам, но это исключение, а не правило)
Тем не менее, электронная почта в пути не гарантируется в зашифрованном виде, и что-либо потенциально чувствительное действительно не следует доверять незашифрованному в Интернет с помощью ЛЮБОГО метода, в том числе электронной почты, поскольку для любого крупного провайдера или телекоммуникационной компании тривиально прослушивать волокна, проходящие через их средства, или протоколировать пакеты, проходящие через их маршрутизаторы.
ФБР регулярно делает это с помощью Carnivore и других программ, и мошеннические элементы были задокументированы и в прошлом.
Все, что путешествует по сети без цифровой подписи или шифрования, может быть легко изменено. Если вам нужна целостная целостность электронной почты, используйте подпись PGP/GPG.
Также вам нужно как-то передать ваш открытый ключ PGP/GPG получателям (чтобы они могли убедиться, что ваши электронные письма действительно ваши). Это своего рода проблема курицы и яйца: это создание безопасного канала связи, но для этого уже требуется безопасный канал связи. Отправка по электронной почте - это нормально, но вам нужно проверить отпечаток ключа PGP/GPG по телефону или другим способом. Публикация на веб-сайте с поддержкой https также является хорошей идеей, поскольку SSL обеспечивает необходимые гарантии целостности транспорта.
Ваш почтовый клиент или сервер (не знаю, какой именно) должен удалить информацию BCC перед отправкой сообщения. Если вы сами отправили сообщение BCC, а затем просмотрели источник, вы не должны нигде найти свой адрес электронной почты, кроме как в строке «От» (проверьте это с помощью моей собственной почты).
Все зависит от сервера. Большинство серверов используют линию BCC и в основном отправляют сообщение один раз на адрес. в основном помещаем адрес bcc в строку отправки cc, следующий адрес в строку cc и отправляем тип вещи. Но все зависит от настройки сервера MAIL. BCC никогда не должен идти дальше, чем ваш сервер исходящей почты.