Если электронная почта - это только доставка по принципу «максимальных усилий», существует ли аналогичный протокол с гарантированной доставкой?

1. Доставка факса НЕ гарантируется - есть много причин, по которым факс может выйти из строя. Назвать несколько:

   • Номер неправильно набран
   • Получение факса без бумаги (и недостаточно умного, чтобы понять)
   • Получение факса без тонера (и недостаточно умного, чтобы понять)
   • Бумага загружена обратной стороной при отправке факса
   • Принимающий факс - это общее устройство, а полученный факс принимается и отбрасывается непреднамеренным получателем.
     
     

2. SMTP ЯВЛЯЕТСЯ протокол на основе TCP. Пожалуйста, проконсультируйтесь RFC 821 и его преемники RFC 2821 и RFC 5321.
   Базовый сетевой протокол (TCP / IP) не имеет ничего общего с надежной доставкой (вещь на уровне протокола приложения).

3. Большинство серверов SMTP хранят журналы того, какие сообщения (отправитель / получатель / идентификатор сообщения) прошли через них, что может быть принято в суде, если вы можете продемонстрировать, что журналы вряд ли были подделаны.
   Проконсультируйтесь с юристом.

4. Есть механизмы, приклеенные к протоколу SMTP и связанным программам для обеспечения доставки (DSN, Return Receipts). Обратите внимание, что они сами по себе являются расширениями для максимального / взаимного сотрудничества (большинство почтовых клиентов позволяют вам не отправлять уведомления о прочтении, а некоторые клиенты не могут выдавать уведомления о прочтении. Некоторые MTA не могут / не будут выдавать квитанции о доставке.
   Я не уверен в допустимости этого - это будет зависеть от суда и любого установленного прецедента. Очередной раз, Проконсультируйтесь с юристом.

Закон часто устанавливает, что факсы считаются принятыми документами, потому что их доставка «гарантирована».

Журналы почтового сервера от отправителя и получателя, вероятно, более надежны, чем подтверждение приема факса.

Подтверждение просто означает, что "a" факс ответил и получил документ.

Журналы сервера могут подтвердить, что «этот конкретный» почтовый ящик получил электронное письмо и прошел через серверы A, B и C, прежде чем попасть в «этот конкретный» почтовый ящик.

Я знаю, что в Канаде электронные письма принимаются судами. В крупных случаях гражданский иск может иметь Антон Пиллер Заказать выполняется для захвата журналов сервера и содержимого почтовых ящиков.

Единственный способ получить гарантированную доставку - это прямая одноранговая доставка. Отправитель должен установить прямое соединение с получателем, а получатель должен подтвердить получение. Электронная почта не протокол одноранговой сети, но протокол промежуточного хранения. Так что нет такой гарантии, которая принимается в суде. Но убедитесь, что протокол пытается быть надежным, и если все серверы в цепочке работают хорошо, то он является надежный.

Но технологическая гарантия доставки (в реальной жизни и по электронной почте / факсу) не дает гарантии на содержание сообщения. Журналы или конверт показывают только то, что была доставка, но не могут показать содержание сообщения. Даже если вы подписываете сообщение, это только гарантирует, что оно не подверглось манипуляциям в пути. Но исходный подписанный контент все еще может быть «Hello world!» вместо "Вы уволены!" и у вас есть только подтверждение того, что а сообщение было отправлено.

Разве это не просто просьба о протоколе на основе TCP, который гарантирует доставку в той же степени, что и факс? Существует ли такой протокол и насколько он укоренился?

Чтобы конкретно ответить на вопрос - такого [сетевого] ​​протокола не существует. Таким образом, данный протокол также не закрепляется.

Однако, в связи с этой темой, есть несколько важных моментов, касающихся того, что имеется в виду в отношении того, что вообще означает или возможна «гарантия» [доставки]:

1. Должны быть средства для аутентификации отправителя. Однако такой возможности нет ни в факсах, ни в электронной почте. Номер ФАКСА "от" можно подделать так же, как адрес электронной почты "от" в спаме / фишинговых сообщениях.
2. Должны быть какие-то средства, чтобы гарантировать неотказ от самого сообщения, чтобы оно не было изменено во время передачи, чтобы даже доказать какие было послано. Опять же, базовые протоколы не дают такой гарантии. PKI (с использованием технологии цифровой подписи в электронной почте, которая хорошо поддерживается, хотя часто не используется из-за сложностей, истекающих сертификатов и т. Д.) В сочетании с симметричным шифрованием и хэшированием сообщений имеет большое значение для обеспечения неотказуемости в электронной почте. Это хорошо зарекомендовавшие себя методы, но они не используются непосредственно в пространстве электронной почты в целом.
3. Должны быть какие-то средства, чтобы гарантировать, что сообщение действительно было доставлено (фактическому предполагаемому) получателю. Журналов на самом деле недостаточно, поскольку они не дают никаких гарантий относительно вышеизложенного, а затем лишь слабо комментируют вероятный предложенная доставка в почтовый ящик (не получателю). Это даже слабее, чем доставка по почте. В соответствии с Единым торговым кодексом (UCC) в праве коммерческой торговли: помимо доставки по согласованному адресу, требуется уведомление о доставке предполагаемому получателю о том, что [товары / сообщение] доступны. Электронная почта сохраняет сообщение только в целевом почтовом ящике, но это не гарантирует, что получатель был уведомлен о его прибытии. Получатель обязан постоянно «проверять», пришло ли сообщение.

Наконец, существует дополнительный (и в значительной степени не поддерживаемый кроссплатформенным) протокол электронной почты для запроса (отправителя) и отправки (получателя) подтверждения / квитанции о доставке. Однако это редко используется, не гарантируется и, наконец, не опровергает получение сообщения получателем ... скорее, они могли либо отказаться от подтверждения получения, либо квитанция не была получена отправителем, либо доставка Ошибка подтверждения между несовместимыми системами электронной почты, которые не поддерживают одну и ту же / версию этой дополнительной функции.

Во многих местах, где требуется гарантированная доставка, используются продукты IBM MQ Series или Sterling Software (недавно купленные IBM).