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

21

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

network-protocols

— 이즈
소스

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

— ewwhite

3

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

— cjc

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

— kzh

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

— Johnth를

18

팩스 배달은 보장되지 않습니다-팩스가 실패 할 수있는 방법은 여러 가지가 있습니다. 몇 가지 예를 들면 다음과 같습니다.
- 잘못된 번호
- 종이에서 팩스 받기 (및 인식하기에는 충분하지 않음)
- 토너 부족으로 팩스 수신 (및 현명하지 못함)
- 팩스를 보낼 때 거꾸로 넣은 용지
- 수신 팩스는 공유 장치이며 수신 한 팩스는 의도하지 않은 수신자가 가져 와서 버립니다.
SMTP 는 TCP 기반 프로토콜입니다. RFC 821 및 후속 RFC 2821 및 RFC 5321에 문의하십시오 .
기본 네트워크 프로토콜 (TCP / IP)은 안정적인 전달 (애플리케이션 프로토콜 수준의 것)과 아무 관련이 없습니다.
대부분의 SMTP 서버는 메시지 (발신자 / 수신자 / 메시지 ID)가 통과 한 메시지의 로그를 보관합니다.이 로그는 변조되지 않았 음을 증명할 수있는 법원에서 허용 될 수 있습니다.
변호사와 상담하십시오 .
배달을 보장하기 위해 SMTP 프로토콜 및 관련 프로그램에 연결된 메커니즘이 있습니다 (DSN, 반송 영수증). 이 자체는 최선의 노력 / 상호 협력 확장입니다 (대부분의 메일 클라이언트는 읽기 영수증을 보내지 않도록 선택할 수 있으며 일부 클라이언트는 읽기 영수증을 발행 할 수 없습니다. 일부 MTA는 배달 영수증을 발행 할 수 없습니다).
나는이의 적격성에 확실하지 않다 - 그것은 법원과 확립 된 판례에 달려 다시. 변호사를 참조하십시오 .

— voretaq7
소스

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!"일 수 있습니다. "당신은 해고당했습니다!"대신 그리고 당신은 단지 것을 확인해야 메시지가 전송되었습니다.

— mailq
소스

3

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

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

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

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

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

— 대럴 티그
소스

2

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

— 우당
소스

여러 회사에서 IBM MQ Series 및 최신 메시징 시스템 (TIBCO, Sterling Commerce 등)을 구현했습니다. 이 제품들은 '보장 된 배달'기능을 가지고 있지만 글씨를 읽으면 그 정의는 그리 철자하지 않습니다. 실제로 메시지의 처리가 '알 수없는'수령인이 메시지를 받았을 수도 있고받지 않았을 수도있는 몇 가지 중요한 경우가 있습니다. 일반적으로 이것은 메시지가 실제로 전달되고 수신자가 응답하지만 발신자 전 / 후에 응답이 손실 될 때 발생합니다.

— Darrell Teague