Чи гарантовано надійність електронних листів BCCing надійними?


29

Іншими словами, чи безпечне припущення, що ніхто з одержувачів ніколи не побачить електронні листи в BCC? Що робити, якщо одержувач є адміністратором поштового сервера (але не відправника) і може вносити будь-які зміни на його сервер?


15
Зазвичай електронна пошта не є захищеною і не є надійною. Якщо одержувач є адміністратором свого сервера, він може зробити для цього майже все.
Лорд Петро

Що того, що варто, у мене виникає проблема із цим банкоматом. stackoverflow.com/questions/31527974 / ...
johnsnails

Відповіді:


21

Ні. SMTP - це протокол простого тексту , використовуючи методи зберігання та пересилання .

Що це означає:

  • Простий текст: кожен сервер, який ретранслює це повідомлення, бачить його в повному обсязі, включаючи всю інформацію заголовка. Хоча кожен одержувач у полі BCC зазвичай отримує власну електронну пошту (тому сервер надсилає індивідуальну електронну пошту, де всі інші одержувачі BCC повинні бути викреслені (наголос на повинен !), На відміну від CC, де дані зберігається), що одна адреса електронної пошти все ще зберігається в заголовках, у простому тексті (ні шифрування, ні обфускування, нічого).
  • Зберігання та пересилання: електронна пошта не обов'язково переходить безпосередньо на поштовий сервер одержувача, але може бути (і зазвичай є) пересилатися через ряд проміжних серверів електронної пошти; він зберігається на кожному (на невизначений проміжок часу) і потім пересилається до наступного стрибка (знову ж таки, не обов'язково до кінцевого пункту призначення).
  • врахуйте, що електронна пошта надсилається за неіснуючою, повною, заблокованою або іншою нефункціональною адресою - копія пошти разом з діагностичними даними може знаходитися в декількох місцях, не всі вони обов'язково поштові скриньки ( наприклад , журнали помилок або поштмейстер поштову скриньку)
  • .

Іншими словами, ваше припущення небезпечно. Якщо ви хочете конфіденційності та безпеки, використовуйте цифрові підписи та шифрування, наприклад GPG; ванільна електронна пошта - неправильний інструмент для такої роботи.


1
Як шифрування вирішує проблему приховування одержувачів?
detly

Це не так, але Piskvor не обов'язково говорив про поштові скриньки одержувача повідомлення при посиланні на конфіденційність, а лише на вміст. AFAIK, як правило, неможливо приховати одержувачів електронного листа, якщо його не можна переслати через проксі-сервери, що не беруть журнал. Якщо ваше повідомлення настільки секретне, що вам потрібно замаскувати одержувачів, а також вміст, вам потрібно знайти інший механізм зв’язку.
afrazier

2
Я був з Пісквором до останнього речення. Якщо все, що ви хочете зробити, це приховати одержувачів один від одного, то вам просто потрібен поштовий клієнт, який може надсилати всі BCC окремо.
Стів Беннетт

@afrazier: Якби я ще не додав конкуруючої відповіді, я би спростував цю, бо не відповідав на питання ОП.
Blrfl

1
Одержувачі BCC не записуються в заголовок електронної пошти (за винятком дуже старих та зламаних MTA). Стандартний поштовий сервер навіть не дивиться на заголовок, він використовує лише конверт, щоб вирішити, куди слід відправляти електронні листи.
Адріан Пронк

13

Будь-який агент передачі пошти (MTA), який повністю відповідає RFC 2822 (конкретно, розділ 3.6.3, поля призначення адреси ), видалить Bcc:поле із заголовка перед спробою доставки, унеможлививши несліпих одержувачів визначити сліпих одержувачів 'особистість.

Є кілька уловів:

  • Якщо ви не маєте контролю над першою MTA, що надходить до вашої вихідної електронної пошти, ви не можете гарантувати, що програмне забезпечення, яке використовується в MTA, виконуватиме інструкція RFC 2822.

  • Той факт, що електронний лист від вас до одержувача, який, можливо, був сліпо скопійований одним або декількома MTA, може зберегтись у журналах цих MTA.


1
Відмінна відповідь, що стосується "ніхто з одержувачів ніколи не побачить електронні листи [адреси] в BCC". Ви можете перевірити, що ваш перший MTA роблять із заголовками BCC, надіславши електронне повідомлення на бот-відповідь електронної пошти, який повертає заголовки вашої електронної пошти.
sabre23t

MTA не повинен бачити навіть Bcc:заголовок; натомість MUA (програма поштового клієнта) повинна вказати всі адреси в конверті SMTP ( MAIL FROM).
grawity

Цей трюк не спрацює у всіх випадках, оскільки стандарти не вимагають, щоб доставка доставляла щось, що може бути вказано адресою одержувача поза заголовками. MTP існував до шести років після вперше визначеної поведінки BCC (RFC 680, 1975); SMTP з'явився через рік.
Blrfl

5

Ніколи не слід вважати, що одержувачі не дізнаються про одержувача BCC. Я мав, що одержувачі BCCed натискають «Відповісти всім» у своїй поштовій програмі, і оголошують усім, що вони отримували пошту раніше, з приголомшливим нерозумінням того, що насправді означає BCCed. Якщо вам дійсно потрібно, щоб воно було приватним, перешліть повідомлення з папки Надіслане після того, як ви надішлете його оригінальним одержувачам, тож єдиною іншою адресою у заголовках повідомлень є ваша.

Це означає, що навіть якщо ви використовуєте BCC, якщо сервер одержувача BCCed відокремлений від початкового одержувача, сервер одержувача не матиме доступу до інформації BCC, як це було б викреслено (або, швидше за все, ніколи не включено до тіло повідомлення) поштовим сервером вашого постачальника.

Зі сторони: SMTP не є ні надійним, ні особливо приватним. Деякі плакати стверджують, що "ланцюги" серверів SMTP існують, але в цілому SMTP надсилає з вашого комп'ютера, до вашого провайдера, до одержувачів ISP. (і як би багато серверів у них не було внутрішньо) Загалом, ваша пошта НЕ буде перенаправлена ​​на поштовий сервер третьої сторони, і насправді такі спроби, як правило, заборонені з антиспамських причин. (Є винятки, оскільки невеликі провайдери та домашні мережі пересилатимуть свого провайдера, але це виняток, не правило)

Зважаючи на це, електронна пошта під час транзиту не гарантується зашифрованою, і нічого потенційно чутливого насправді не слід довіряти незашифрованому до Інтернету будь-яким методом, включаючи електронну пошту, оскільки це банально для будь-якого великого постачальника або telco, щоб натискати на волокна, що проходять через їхні засоби або пакети журналів, що подорожують через маршрутизатори.

ФБР регулярно робить це завдяки хижакам та іншим програмам, і недобросовісні елементи були задокументовані, роблячи це і в минулому.


1
I've had BCCed recipients hit "Reply All" in their mail program Цього ніколи не траплялося зі мною, але я бачив, як це траплялося не раз. Ваша порада (не коп, а вперед після відправки) - саме те, що я і роблю. Я ненавиджу звучати як зарозумілий ривок, але іноді доводиться захищати людей від себе.
Dan7119

@ Dan7119 Дозвольте здогадатися .. Ви / також були систематиком?
SplinterReality

Чудова відповідь. Навіть якщо зачистка інформації BCC є на 100% достовірною, людський фактор BCCed recipients hit "Reply All"не гарантується надійним. Я погоджуюсь forward the message from your Sent folderособливо з недоброзичливими одержувачами BCCed, такими як генеральні директори.
sabre23t

1

Ваш електронний клієнт або сервер (не знаю, який) повинен викреслити інформацію BCC перед тим, як надсилати повідомлення. Якщо ви BCC самостійно надсилаєте повідомлення, а потім переглядаєте джерело, ви не повинні знаходити свою електронну адресу ніде, окрім рядка "Від" (це підтверджено моєю власною поштою).


Дякую. Але моє питання насправді глибше і щодо надійності та безпеки. Не те, як це повинно бути в теорії.
qwerty

Ну, наскільки я знаю, спосіб дізнатися, чи відповідає теорія практиці, - це BCC самостійно на електронний лист, переглянути джерело та побачити, чи є там адреса BCC.
zpletan

Ваш електронний клієнт не викреслює інформацію BCC. Це не має сенсу.
Стів Беннетт

1

Все залежить від сервера. Більшість серверів займуть рядок BCC і в основному надсилають повідомлення один раз за адресою. в основному, введення bcc-адреси у cc-рядок відправлення, наступна адреса в рядок cc і надіслати тип речі. Але все залежить від налаштування сервера MAIL. BCC ніколи не повинен зайти далі, ніж ваш сервер вихідної пошти.


7
Помилково на три бали. По-перше, саме Bcc:заголовки MUA, а не SMTP-сервери займаються заголовками. На той час, коли речі дістаються до SMTP-сервера, адреси одержувачів знаходяться в конверті повідомлень , а не в заголовках. По-друге, лише сервери подання SMTP коли-небудь переписують такі заголовки в першу чергу. По-третє, повідомлення завжди надсилаються один раз на одержувача конвертів. Це не особливе чи інше.
JdeBP

1

Все, що подорожує мережею без цифрового підпису чи шифрування, може бути легко змінено. Якщо вам потрібна цілісна цілісність електронної пошти, використовуйте підпис PGP / GPG.

Також вам потрібно буде якось передати ваш публічний ключ PGP / GPG одержувачам (щоб вони могли перевірити, що ваші повідомлення електронної пошти справді ваші). Її проблема з куркою та яйцями: це встановити безпечний канал зв'язку, але він вже потребує безпечного каналу комунікацій. Надіслати його електронною поштою - це нормально, але вам потрібно підтвердити відбиток ключа PGP / GPG по телефону або іншими способами. Опублікування його на веб-сайті з підтримкою https також є хорошою ідеєю, оскільки SSL забезпечує необхідні гарантії цілісності транспорту.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.