수신자 일 때 숨은 참조 필드에서 이메일 주소의 마스크를 해제하려면 어떻게해야합니까?

코드를 작성하지 않는 사람을위한 매우 간단한 단계별 지침이 필요합니다. 저는 그룹 이메일을 받았으며이를받은 다른 사람을보고 싶습니다.

댓글

  • 이 작업을 할 수 없다는 것이 숨은 참조의 정확한 요점입니다.
  • 느낌이 있습니다. ' 직장에서 오는 후속 질문입니다 .SE
  • BCC를 확인하려면 이메일을 보낸 SMTP 서버를 해킹하고 수신 로그를 해독해야합니다. 이를 달성하는 데 어려움을 겪을 가능성이 높습니다 …
  • @chrylis 공정하게 말하면 ' 접근해서는 안되는 정보가 그저 숨겨져 서 가능하다고 생각하는 방법을 이해할 수 있습니다.
  • 쉬운 것은 없습니다. 보낸 사람을 고소한 다음 소환장을 사용하여 원본 메시지를 공개하도록 강요합니다.

답변

할 수 없습니다. 메일을받을 때 “숨은 참조 헤더에 대한 정보가 없기 때문에”마스크 해제 “할 항목이 없습니다.

숨은 참조의 디자인 방식은 RFC 2822 , 섹션 3.6.3. 사양을 인용하려면 :

“Bcc :”필드 ( “Bcc”는 “Blind Carbon Copy”를 의미)에는 메시지 수신자 주소가 포함됩니다. 그 주소는 메시지의 다른 수신자에게 공개되지 않습니다. “숨은 참조 :”필드를 사용하는 방법에는 세 가지가 있습니다. 첫 번째 경우, “숨은 참조 :”필드가 포함 된 메시지를 보낼 준비가되면 모든 수신자 ( “숨은 참조 :”필드에 지정된 수신자 포함)가 전송 되어도 “숨은 참조 :”줄이 제거됩니다. 메시지 사본. 두 번째 경우에는 “To :”및 “Cc :”행에 지정된 수신자에게 각각 위와 같이 “Bcc :”행이 제거 된 메시지 사본이 전송되지만 “Bcc :”행의 수신자는 “숨은 참조 :”줄이 포함 된 별도의 메시지 사본. ( “Bcc :”필드에 여러 수신자 주소가있는 경우 일부 구현에서는 실제로 특정 수신자의 주소 만 포함하는 “Bcc :”와 함께 각 수신자에게 별도의 메시지 사본을 보냅니다.) 마지막으로 “Bcc :” : “필드에는 주소가 없을 수 있습니다.”숨은 참조 : “필드는 수신자에게 숨은 참조가 누군가에게 전송되었음을 알리는 주소없이 전송 될 수 있습니다. “숨은 참조 :”필드와 함께 사용할 방법은 구현에 따라 다르지만 각각에 대한 설명은이 문서의 “보안 고려 사항”섹션을 참조하십시오.

메시지가 다른 메시지에 대한 응답 인 경우 원본 메시지 작성자의 사서함 ( “보낸 사람 :”필드의 사서함) 또는 “답장 :”필드에 지정된 사서함 (존재하는 경우)은 이러한 이유로 응답의 “받는 사람 :”필드에 나타날 수 있습니다. 일반적으로 응답의 기본 수신자가됩니다. 대상 필드가있는 메시지에 회신을 보내는 경우 작성자와 함께 메시지의 모든 수신자에게 회신 사본을 보내는 것이 바람직한 경우가 많습니다. 이러한 회신이 형성되면 원본 메시지의 “받는 사람 :”및 “참조 :”필드에있는 주소는 일반적으로 회신의 2 차 수신자이므로 회신의 “참조 :”필드에 나타날 수 있습니다. 원본 메시지에 “숨은 참조 :”필드가있는 경우 해당 필드의 주소는 회신의 “숨은 참조 :”필드에 나타날 수 있지만 “받는 사람 :”또는 “참조 :”필드에는 나타나지 않아야합니다.

참고 : 일부 메일 응용 프로그램에는 회신의 대상 주소에 원본 메시지의 대상 주소를 포함하는 자동 회신 명령이 있습니다. 이러한 응답 명령의 작동 방식은 구현에 따라 다르며이 문서의 범위를 벗어납니다. 특히 원본 메시지에 “Reply-To :”필드가있을 때 원래 대상 주소를 포함할지 여부는 여기에서 다루지 않습니다.

In 받는 사람 및 참조받는 사람이 숨은 참조 줄을받지 못하지만 각 숨은 참조 주소는 자신의 전자 메일 주소 만 포함 된 숨은 참조 줄을받는 경우가 가장 일반적입니다. 이렇게하면받는 사람과 참조받는 사람에게 숨은 참조를 표시하지 않고 다른 Bcc 수신자를 공개하지 않고 Bcc를 사용하여 이메일을 보낸 Bcc “수신자.

Comments

  • each Bcc'ed address receives a Bcc line containing only their email address, is most common. 맞나요? 여러 RCPT TO: 명령을 사용하는 단일 메시지 대신 메시지를 여러 번 보내야합니다. MUA는 무엇을할까요?
  • @EsaJokinen 수신자가 다른 도메인에있을 때 MUA는 어떤 다른 선택을 할 수 있습니까? BCC는 단순히 이러한 동작을 강제합니다.
  • MUA는 MTA에 한 번만 전송하고 MTA는 모든 다른 도메인에 개별적으로 전달하기 시작합니다.문제는 MTA가 ' 일반적으로 RCPT TOBcc:로 추가하지 않아도된다는 것입니다. ' Received: 헤더에서 for <[email protected]> 일 가능성이 더 높습니다.
  • 그 ' 사실입니다. ' d (또는 공개되지 않은 상태)가

    & Cc 헤더. MUA는 보낸 사람 Sent-folder에 메일을 저장할 때 Bcc 만 저장하지만 SMTP를 통해 전송 된 메시지의 일부가 ' .

  • @EsaJokinen Gmail은이 작업을 수행합니다. 실제로 메일에 Bcc 헤더가 포함됩니다. 나는 '이 작업을 수행하는 다른 사람을 알지 못합니다.

답변

일반적으로이 필드는 수신자 SMTP 서버로 전송되지 않으므로 발신자 SMTP 서버를 제어 할 수없는 경우 불가능합니다.

메일을 보낼 때 발신자 SMTP 서버는 숨은 참조 입력란을 만들고 나열된 각 수신자에 대한 사본을 만들어 다른 수신자 목록을 제거합니다. 이것이 숨은 참조 기능의 전체 요점입니다.

답변

RFC (Request For Comments) 표준 (IETF (Internet Engineering Task Force)에서 게시)은 “BCC”헤더에 지정된 수신자에게 전송 된 이메일 수신자가 이메일을 수신 할 수 있지만 다른 정보는 인식하지 못하도록 지정합니다. 특히 “주소는 메시지의 다른 수신자에게 공개되지 않아야합니다.”라는 메시지가 표시됩니다.

이는 SMTP 서버에 대한 현재 관행 (프로토콜)을 반영하기위한 요청 (명령이 아님)입니다. 인터넷 커뮤니티 b y 인터넷 사회.

그러나 준수하지 분리 될 수 있으며 불량으로 판명되면 금지 / 블랙리스트에 올릴 수 있으며 때 관할 지역의 법률을 위반하는 활동을 수행 한 것으로 확인되었습니다.

따라서 준수 (메일) 서버에서 보낸 이메일을 수신 한 경우 다른 이메일을 수신 할 수 없습니다. 송신 (SMTP) 서버, 수신 (POP, IMAP 등) 서버 및 IP 패킷을 라우팅 한 모든 릴레이 서버를 제어하지 않는 한 “숨은 참조”필드에 언급 된 수신자 이메일.

댓글

  • " 규정을 준수하지 않는 것으로 확인 된 항목은 분리 될 수 있으며 불량으로 확인 된 경우, 금지 / 블랙리스트에 올릴 수 있으며, 관할권의 법률을 위반하는 행위가 발견 될 경우 기소 될 것입니다. " -저는 고소 할 것입니다. ggest 이것은 BCC 주소를 유출 한 서버에 대해 매우 드문 결과입니다. 또한 메시지가 [email protected][email protected]에 대한 BCC ' d이고 foo.com 및 y.com에 다른 SMTP 서버가있는 경우 bar.com은 [email protected] '의 주소도 유출되지 않으므로 " 분리 " 유출은 자체 사용자에게만 영향을 미치므로
  • 현재 이메일 시스템에 대한 IETF RFC 준수를 요구하는 법률이 있습니까?
  • @grawity : You ' 모범 사례 , 일반적으로 허용되는 방법 및 유사한 일반 진술 적용을 금지하는 법률을 찾고 있습니다. Cf. GDPR 5.1 (f) " 적절한 기술적 또는 조직적 조치 "
  • @MSalters는 아마도 처방 그 반대가 아니라 proscribe
  • @grawity 표준에도 불구하고 정보를 공개 한 서버는 운영자가 다양한 개인 정보 보호법 ( GDPR 또는 CCPA 등)

답글 남기기

이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다