Se o e-mail for apenas a entrega do "melhor esforço", existe um protocolo semelhante com entrega garantida?

Question

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

    

Answer 1

1. A entrega de fax NÃO é garantida - há muitas maneiras de um fax falhar. Para citar alguns:

   • Número de discagem incorreta
   • Receber fax sem papel (e não inteligente o suficiente para perceber)
   • Receber fax sem toner (e não inteligente o suficiente para perceber)
   • Papel carregado de cabeça para baixo no envio de fax
   • Receber fax é um dispositivo compartilhado e o fax recebido é recebido e descartado por destinatário não intencional
     
     

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

3. A maioria dos servidores SMTP mantém registros de quais mensagens (remetente / destinatário / ID da mensagem) passaram por eles, o que pode ser admissível nos tribunais se você puder demonstrar que os registros provavelmente não foram adulterados. em> Consulte um advogado .

4. Existem mecanismos colados no protocolo SMTP e nos programas associados para garantir a entrega (DSN, Recibos de devolução). Observe que essas são extensões de cooperação mútua (a maioria dos clientes de e-mail permite que você não envie recibos de leitura e alguns clientes não podem emitir um recibo de leitura. Alguns MTAs não podem / não emitirão um recibo de entrega.
   Não tenho certeza sobre a admissibilidade deles - isso dependeria do tribunal e de qualquer precedente estabelecido. Mais uma vez, Consulte um advogado .

Answer 2

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

Os registros do servidor de e-mail do remetente e dos destinatários são provavelmente mais confiáveis do que a confirmação da recepção do fax.

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

Os registros 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 emails são aceitos nos tribunais. Em grandes casos, um processo civil pode ter um Pedido do Anton Piller executado para aproveitar o conteúdo de logs e caixas de correio do servidor.

    

Answer 3

A única maneira de ter uma entrega garantida é uma entrega direta de peer-to-peer. O remetente deve estabelecer uma conexão direta com o destinatário e o destinatário deve confirmar a recepção. E-mail não é um protocolo peer-to-peer, mas um protocolo de armazenamento e encaminhamento. Portanto, não há esse tipo de garantia que seja aceita no tribunal. Mas com certeza o protocolo tenta ser confiável e se todos os servidores na cadeia jogarem bem, então é confiável.

Mas a garantia de entrega tecnológica (na vida real e no 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 assinado original ainda pode ser "Hello world!" em vez de "você está demitido!" e você só tem a confirmação de que a mensagem a foi enviada.

    

Answer 4

Isn't this just begging for a TCP-based protocol that guarantees delivery to the same degree that fax does? Does such a protocol exist, and how entrenched is it?

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

No entanto, relacionado a esse tópico, há alguns pontos importantes sobre o que significa 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 FAX nem no processo de agitar a mão por e-mail. O número de fax "de" pode ser falsificado, assim como o endereço de email "de" está em tantas mensagens de spam / phishing.
2. Deve haver alguns meios para garantir o não repúdio da própria mensagem, de modo que ela não seja modificada em trânsito para até mesmo provar o que foi enviado. Mais uma vez, os protocolos subjacentes não fazem tal garantia. PKI (usando tecnologia de assinatura digital em e-mail, que é bem suportada, embora não seja utilizada devido a complexidades, expirando certificados, etc.), juntamente com criptografia simétrica e hash de mensagens são muito úteis para fornecer não-repúdio em e-mail. Estes são métodos bem entrincheirados, mas não diretamente no espaço de comunicação por e-mail em geral.
3. Deve haver algum meio de garantir que a mensagem foi realmente entregue ao destinatário (real pretendido). Os logs são realmente insuficientes, uma vez que eles não fazem nenhuma garantia quanto ao acima e, em seguida, apenas anota fracamente uma provável entrega oferecida para a caixa de correio (não o destinatário). Isso é ainda mais fraco que a entrega postal. De acordo com o Código Comercial Uniforme (UCC) na lei de comércio 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 apenas armazena a mensagem na caixa de correio de destino, mas isso não garante que o destinatário tenha sido notificado de sua chegada. Cabe ao receptor "checar" constantemente se a mensagem chegou.

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

    

Answer 5

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