Se o email é apenas a entrega do "melhor esforço", existe um protocolo semelhante com entrega garantida?

Muitas vezes, é estabelecido por lei que os faxes são documentos aceitos porque a entrega é "garantida", enquanto o e-mail não é porque a entrega não é. Isso não está apenas implorando por um protocolo baseado em TCP que garanta a entrega no mesmo grau que o fax? Esse protocolo existe e como está entrincheirado?

1. A entrega de fax NÃO é garantida - Há várias maneiras pelas quais um fax pode falhar. Para nomear alguns:

   • Número discado incorretamente
   • Receber fax sem papel (e não suficientemente inteligente para perceber)
   • Receber fax sem toner (e não suficientemente inteligente para perceber)
   • Papel carregado de cabeça para baixo no envio de fax
   • O recebimento de fax é um dispositivo compartilhado e o fax recebido é capturado e descartado pelo destinatário não intencional
     
     

2. SMTP É um protocolo baseado em TCP. Consulte o RFC 821 e seus sucessores, o RFC 2821 e o RFC 5321 .
   O protocolo de rede subjacente (TCP / IP) não tem nada a ver com entrega confiável (uma coisa no nível do protocolo do aplicativo).

3. A maioria dos servidores SMTP mantém registros de quais mensagens (remetente / destinatário / messageID) passaram por eles, o que pode ser admissível em tribunal se você puder demonstrar que é improvável que os registros tenham sido adulterados.
   Consulte um advogado .

4. Existem mecanismos colados no protocolo SMTP e programas associados para garantir a entrega (DSN, Return Receipts). Observe que elas mesmas são extensões de cooperação mútua / de melhor esforço (a maioria dos clientes de correio permite que você não envie confirmações de leitura e alguns clientes não podem emitir uma confirmação de leitura. Alguns MTAs não podem / não emitem uma confirmação de entrega.
   Não tenho certeza da admissibilidade deles - isso dependeria do tribunal e de qualquer precedente estabelecido.Mais uma vez, consulte um advogado .

É geralmente estabelecido por lei que os faxes são documentos aceitos porque a entrega é 'garantida'

Os logs do servidor de email do remetente e destinatários são provavelmente mais confiáveis ​​do que a confirmação da recepção de fax.

A confirmação implica simplesmente que "um" fax respondeu e recebeu o documento.

Os logs do servidor podem confirmar que a caixa de correio "específica" recebeu o email e passou pelo servidor A, B e C antes de entrar na caixa de correio "específica".

Eu sei que no Canadá os e-mails são aceitos nos tribunais. Em casos grandes, uma ação civil pode ter uma Ordem Anton Piller executada para aproveitar o conteúdo dos logs e caixas de correio do servidor.

A única maneira de obter uma entrega garantida é uma entrega direta ponto a ponto. O remetente deve estabelecer uma conexão direta com o destinatário e o destinatário deve confirmar a recepção. O email não é um protocolo ponto a ponto, mas um protocolo de armazenamento e encaminhamento. Portanto, não existe esse tipo de garantia que seja aceita em tribunal. Mas, com certeza, o protocolo tenta ser confiável e, se todos os servidores da cadeia funcionam bem, é confiável.

Mas a garantia de entrega tecnológica (na vida real e em correio eletrônico / fax) não garante o conteúdo da mensagem. Os logs ou envelope mostram apenas que houve uma entrega, mas não podem mostrar o conteúdo da mensagem. Mesmo se você assinar uma mensagem, é garantido que ela não foi manipulada no caminho. Mas o conteúdo original assinado ainda pode ser "Olá, mundo!" em vez de "Você está demitido!" e você só tem a confirmação de que uma mensagem foi enviada.

Isso não está apenas implorando por um protocolo baseado em TCP que garanta a entrega no mesmo grau que o fax? Esse protocolo existe e como está entrincheirado?

Para responder especificamente à pergunta - não existe esse protocolo [de rede]. Assim, também não há entrincheiramento do referido protocolo.

No entanto, relacionado a este tópico, há alguns pontos importantes sobre o que se quer dizer sobre o que "garantia" [de entrega] significa ou é possível:

1. Deve haver um meio de autenticar o remetente. No entanto, não existe tal facilidade no processo de envio de fax nem de agitar as mãos por e-mail. O número de fax "de" pode ser falsificado, tanto quanto o endereço de email "de" está em muitas mensagens de spam / phishing.
2. Deve haver alguns meios para garantir o não repúdio à própria mensagem, de forma que ela não tenha sido modificada em trânsito para provar o que foi enviado. Novamente, os protocolos subjacentes não oferecem essa garantia. A PKI (usando a tecnologia de assinatura digital no email, que é bem suportada, embora muitas vezes não seja usada devido a complexidades, certificados expirados etc.), juntamente com criptografia simétrica e hash de mensagem, é um longo caminho para fornecer não-repúdio no email. Estes são métodos bem estabelecidos, mas não diretamente no espaço de comunicação por email.
3. Deve haver alguns meios para garantir que a mensagem foi realmente entregue ao destinatário (realmente pretendido). Na verdade, os logs são insuficientes, pois não garantem o que foi dito acima e, em seguida, anotam apenas uma entrega provavelmente com proposta para a caixa de correio (não para o destinatário). Isso é ainda mais fraco que a entrega postal. De acordo com o Código Comercial Uniforme (UCC) na legislação comercial: além da entrega no endereço acordado, é necessária uma comunicação da entrega ao destinatário pretendido de que as [mercadorias / mensagem] estão disponíveis. O email armazena apenas a mensagem na caixa de correio de destino, mas isso não garante que o destinatário tenha sido notificado sobre sua chegada. Cabe ao receptor verificar constantemente se a mensagem chegou.

Por fim, existe um protocolo de e-mail opcional (e amplamente não compatível com várias plataformas) para solicitar (remetente) e enviar (destinatário) uma confirmação / recibo de entrega. No entanto, isso raramente é usado, não é garantido e, por fim, não desaprova o recebimento da mensagem pelo destinatário ... em vez disso, eles podem optar por não confirmar o recebimento, o recebimento não foi recebido pelo remetente ou a entrega a confirmação falhou entre sistemas de email incompatíveis que não suportam a mesma / versão deste recurso opcional.

Muitos locais que exigem entrega garantida usam os produtos IBM MQ Series ou Sterling Software (comprados recentemente pela IBM)