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


21

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


흥미로운 질문입니다. 메일 시스템이 완벽하지 않으며 다양한 요소가 배달에 영향을 줄 수 있다고 최종 사용자에게 설명해야합니다.
ewwhite

3
본질적으로 사회적 문제에 대한 기술적 해결책을 제시하려고 생각합니다. 메시지를 팩스 나 인터넷을 통해 보내는 지 여부에 상관없이 메시지 수신자가 실제로 해당 메시지에 눈알을 뿌릴 수는 없습니다.
cjc

두 장군 문제는 로켓 붐에 의해 설명 : rocketboom.com/two-generals
kzh

기술 또는 법적 관점에서 어떤 전달에 대해 이야기하고 있습니까? 법적 측면에 대해 이야기하는 경우 국가도 지정해야합니다.
Johnth를

답변:


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

    • 잘못된 번호
    • 종이에서 팩스 받기 (및 인식하기에는 충분하지 않음)
    • 토너 부족으로 팩스 수신 (및 현명하지 못함)
    • 팩스를 보낼 때 거꾸로 넣은 용지
    • 수신 팩스는 공유 장치이며 수신 한 팩스는 의도하지 않은 수신자가 가져 와서 버립니다.

  2. SMTP TCP 기반 프로토콜입니다. RFC 821 및 후속 RFC 2821RFC 5321에 문의하십시오 .
    기본 네트워크 프로토콜 (TCP / IP)은 안정적인 전달 (애플리케이션 프로토콜 수준의 것)과 아무 관련이 없습니다.

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

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


SMTP가 TCP 기반이 아님을 암시하려고하지 않았습니다.
Jez

11
@Jaz-나는 당신이 그것을 알고 있다고 확신했지만 귀하의 질문이 표현 된 방식은 신뢰할 수있는 데이터 그램 전송 (TCP 대 UDP)과 전체 메시지의 안정적인 전달 (응용 프로그램 문제)의 두 가지 문제를 해결합니다. 단서가 적은 사람이이 질문에 1 년 정도 걸려 넘어 질 때 나는 그들이 잘못된 생각을
갖기를

법적인 관점에서, 팩스를 성공적으로 보내면 성공적으로 배달됩니다.
Johnth를

@SmitJohnth "나의 팩스 스테이션이 성공적으로 보냈다고 말한 것"(특히 내가 언급 한 첫 번째 글 머리 기호)이 팩스 전송을 받게됩니다. 잘못된 주소에 대한 통지를 제공 할 수없고 유효한 것으로 주장 할 수있는 것처럼, 마지막 글 머리 기호는 공유 팩스기와 공동 작업 공간에서 경합하는 영역입니다. 하지만 논쟁의 여지가 많다).
voretaq7

@ voretaq7 글쎄, 당신은 당신이 말하는 땅을 지정해야합니다. Rammstein의 노래와 반대로, 아무도 Amerrika에 살고 있지 않습니다 :) 내 땅에 AFAIK가 올바른 번호로 팩스를 성공적으로 보낸다는 것은 법적 관점에서 성공적인 배달을 의미합니다.
Johnth

9

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

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

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

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

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


3
송신 측에서 팩스 확인을받습니다. 이메일의 성공적인 전달 확인은 수신 측에서만 볼 수 있습니다. 보낸 사람은 메일이 다음 홉 (대상은 아님)으로 배달되었음을 알고 있습니다.
mailq

@mailq, 동의합니다. 그러나 다시 한 번 팩스 확인을 통해 올바른 대상에 도달했음을 확인할 수는 없습니다. 그래서 보낸 사람과받는 사람의 서버 로그가 모두 팩스 수신 확인보다 나쁘지 않다고 말했습니다.
Alex

1
팩스 확인은 팩스가 잘못된 대상으로 전송되었음을 확인합니다. 수신자의 번호가 표시됩니다. 이 숫자가 잘못되었다는 것은 기술의 결함이 아니라 사람의 실수입니다.
mailq

발신자 ID에서 수신 한 것이 아니라 수신자가 설정 한 "수신자 번호" 가 표시되므로 전화를 건 실제 번호는 아닙니다.
Piskvor

@Piskvor : 내가 사용한 대부분의 팩스기 는 배달 확인 페이지에 전화 번호를 입력합니다.
스냅

4

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

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


3

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

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

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

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

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


2

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


여러 회사에서 IBM MQ Series 및 최신 메시징 시스템 (TIBCO, Sterling Commerce 등)을 구현했습니다. 이 제품들은 '보장 된 배달'기능을 가지고 있지만 글씨를 읽으면 그 정의는 그리 철자하지 않습니다. 실제로 메시지의 처리가 '알 수없는'수령인이 메시지를 받았을 수도 있고받지 않았을 수도있는 몇 가지 중요한 경우가 있습니다. 일반적으로 이것은 메시지가 실제로 전달되고 수신자가 응답하지만 발신자 전 / 후에 응답이 손실 될 때 발생합니다.
Darrell Teague
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.