[server] 전자 메일이 “최선의 노력”배달 인 경우 배달이 보장되는 유사한 프로토콜이 있습니까?

전자 우편은 배달이 아니기 때문에 팩스가 배달이 ‘보장’되어 있기 때문에 팩스가 승인 된 문서라는 것이 법에 의해 종종 확립됩니다. 이것은 팩스와 같은 수준으로 배달을 보장하는 TCP 기반 프로토콜을 요구하지 않습니까? 그러한 프로토콜이 존재하고 얼마나 확고한가?



답변

  1. 팩스 배달은 보장되지 않습니다-팩스가 실패 할 수있는 방법은 여러 가지가 있습니다. 몇 가지 예를 들면 다음과 같습니다.

    • 잘못된 번호
    • 종이에서 팩스 받기 (및 인식하기에는 충분하지 않음)
    • 토너 부족으로 팩스 수신 (및 현명하지 못함)
    • 팩스를 보낼 때 거꾸로 넣은 용지
    • 수신 팩스는 공유 장치이며 수신 한 팩스는 의도하지 않은 수신자가 가져 와서 버립니다.
  2. SMTP TCP 기반 프로토콜입니다. RFC 821 및 후속 RFC 2821RFC 5321에 문의하십시오 .
    기본 네트워크 프로토콜 (TCP / IP)은 안정적인 전달 (애플리케이션 프로토콜 수준의 것)과 아무 관련이 없습니다.

  3. 대부분의 SMTP 서버는 메시지 (발신자 / 수신자 / 메시지 ID)가 통과 한 메시지의 로그를 보관합니다.이 로그는 변조되지 않았 음을 증명할 수있는 법원에서 허용 될 수 있습니다.
    변호사와 상담하십시오 .

  4. 배달을 보장하기 위해 SMTP 프로토콜 및 관련 프로그램에 연결된 메커니즘이 있습니다 (DSN, 반송 영수증). 이 자체는 최선의 노력 / 상호 협력 확장입니다 (대부분의 메일 클라이언트는 읽기 영수증을 보내지 않도록 선택할 수 있으며 일부 클라이언트는 읽기 영수증을 발행 할 수 없습니다. 일부 MTA는 배달 영수증을 발행 할 수 없습니다).
    나는이의 적격성에 확실하지 않다 – 그것은 법원과 확립 된 판례에 달려 다시. 변호사를 참조하십시오 .


답변

팩스 전송이 ‘보증’되므로 팩스가 허용되는 문서 인 경우가 종종 있습니다.

발신자와 수신자의 전자 메일 서버 로그는 팩스 수신 확인보다 더 안정적 일 수 있습니다.

확인은 단순히 “a”팩스가 문서를 수신하고 수신했음을 나타냅니다.

서버 로그는 “특정”사서함이 전자 메일을 수신하고 “특정”사서함에 들어가기 전에 서버 A, B 및 C를 통과했음을 확인할 수 있습니다.

캐나다에서는 법정에서 이메일이 허용된다는 것을 알고 있습니다. 대부분의 경우 민사 소송에서 Anton Piller Order를 실행하여 서버 로그 및 메일 함 컨텐츠를 압류 할 수 있습니다 .


답변

배달을 보장 할 수있는 유일한 방법은 직접 피어 투 피어 배달입니다. 발신자는 수신자와 직접 연결해야하며 수신자는 수신을 확인해야합니다. 이메일은 하지 피어 – 투 – 피어 프로토콜하지만, 저장 및 전달 프로토콜입니다. 따라서 법정에서 인정되는 그런 종류의 보증은 없습니다. 그러나 프로토콜이 신뢰할 수 있는지 확인하고 체인의 모든 서버가 제대로 작동 하면 신뢰할 수 있습니다.

그러나 기술 전달 보증 (실제 및 전자 우편 / 팩스)은 메시지 내용을 보증하지 않습니다. 로그 또는 봉투는 배달이 있었음을 나타내지 만 메시지 내용을 표시 할 수 없습니다. 메시지에 서명 한 경우에도 메시지가 조작되지 않았 음을 보증합니다. 그러나 원래 서명 된 콘텐츠는 여전히 “Hello world!”일 수 있습니다. “당신은 해고당했습니다!”대신 그리고 당신은 단지 것을 확인해야 메시지가 전송되었습니다.


답변

이것은 팩스와 같은 수준으로 배달을 보장하는 TCP 기반 프로토콜을 요구하지 않습니까? 그러한 프로토콜이 존재하고 얼마나 확고한가?

질문에 구체적으로 대답하기 위해 그러한 [네트워크] 프로토콜이 존재하지 않습니다. 따라서 마찬가지로 상기 프로토콜의 보장이 없다.

그러나이 주제와 관련하여 “배송 보증”이 무엇을 의미하는지 또는 가능한지에 대한 중요한 점이 있습니다.

  1. 발신자를 인증 할 수단이 있어야합니다. 그러나 팩스 나 이메일 핸드 셰이 킹 프로세스에는 이러한 기능이 없습니다. “보낸 사람”이메일 주소가 너무 많은 스팸 / 피싱 메시지에 들어 있기 때문에 “보낸 사람”팩스 번호는 스푸핑 될 수 있습니다.
  2. 그것도 증명에-전송 수정되지 않았 자체는 그 메시지의 부인 방지 보장하기 위해 몇 가지 방법이 있어야 무엇을 전송했습니다. 다시 말하지만 기본 프로토콜은 그러한 보장을하지 않습니다. 대칭 암호화 및 메시지 해싱과 결합 된 PKI (복잡성, 인증서 만료 등으로 인해 자주 사용되지는 않지만 전자 메일에서 디지털 서명 기술 사용)는 전자 메일의 부인 방지를 위해 먼 길을 가고 있습니다. 이것들은 잘 확립 된 방법이지만 이메일 통신 공간에서 직접적으로 큰 것은 아닙니다.
  3. 메시지가 실제로 (실제로) 수신자에게 전달되었음을 보장 할 수단이 있어야합니다. 로그는 위의 내용을 보증하지 않고 우편함 (수신자가 아님)으로 전달 된 약한 주석에만 약한 주석을 달기 때문에 실제로 불충분 합니다. 이것은 우편 배달보다 약합니다. 상업 거래법의 UCC (Uniform Commercial Code)에 따르면, 합의 된 주소로의 배달 외에도 [상품 / 메시지]가 가능하다는 의도 된 수령인에게의 배달 통신이 필요합니다. 전자 메일은 대상 사서함에만 메시지를 저장하지만받는 사람에게 도착했음을 알리지 않습니다. 수신자가 메시지가 도착했는지 지속적으로 ‘확인’해야한다.

마지막으로, 배달 확인 / 수신을 요청 (발신자)하고 발송 (수신자) 할 수있는 선택적 (대부분의 크로스 플랫폼 지원) 이메일 프로토콜이 있습니다. 그러나 이것은 거의 사용되지 않으며 보증되지 않으며 마지막으로 수신자의 메시지 수신을 반증하지 않습니다 … 오히려 영수증을 확인하지 않기로 선택했을 수 있습니다. 이 선택적 기능의 동일 / 버전을 지원하지 않는 호환되지 않는 전자 메일 시스템간에 확인에 실패했습니다.


답변

보장 된 배송이 필요한 많은 곳에서 IBM MQ Series 또는 Sterling Software 제품 (최근에 IBM에서 구매)을 사용합니다.


답변