바운스 메시지

바운스 메시지 또는 단순히 "바운스"는 전자 메일시스템으로부터의 자동 메시지이며, 메시지가 배달되지 않았거나 다른 배달 문제가 발생했음을 이전 메시지를 보낸 사람에게 알립니다.원래 메시지는 "버림받았다"고 합니다.

이 피드백은 즉시(여기서 설명하는 원인의 일부) 또는 송신 시스템이 재시도할 수 있는 경우 재시도 종료 후 며칠 후에 도착할 수 있습니다.

바운스 메시지에 대한 보다 공식적인 용어로는 "Non-Delivery Report" 또는 "NDR", [Failed] "Delivery Status Notification" (DSN) 메시지 또는 "NDN"^[1] (Non-Delivery Notification) 등이 있습니다.

바운스 분류

SMTP는 30년 이상 걸리는 성숙한 테크놀로지이지만 아키텍처는 일반 부하와 ^[2]비송신 부하로 인해 점점 더 압박을 받고 있습니다.전자 메일 시스템은 전자 메일의 실제 보낸 사람과 연결된 평판 시스템으로 향상되었으며,^[3] 프로토콜에서 위조된 보낸 사람이 사용될 때 수신자의 전자 메일 서버가 전자 메일을 거부한다는 개념입니다.따라서 두 가지 유형의 이메일 바운스가 생성되었습니다: 하드 바운스와 소프트 바운스.^[4]E-메일 서비스 프로바이더(ESP)는, E-메일을 유저의 수신 트레이에 송신할 때에, 합계 반송율을 결정 요소로 간주하기 때문에, 양쪽 모두 송신자의 IP 평판에 영향을 줍니다.간단히 말하면, 총 바운스 속도는 하드 바운스 레이트와 소프트 바운스 레이트의 합으로 계산됩니다.

힘차게 튀다

하드 바운스는 영속적이며 송신자의 IP 손상 측면에서 더 높은 점수를 받습니다.하드 바운스는 발신인의 메일서버가 수신인을 사용할 수 없고 수신인을 계속 사용할 가능성이 높다고 판단했을 때 발생합니다.전자 메일 수신자가 잘못된 식별자/잘못된 도메인(전자 메일 주소 또는 도메인의 오타 등) 또는 서버가 전자 메일을 더 이상 수신하지 않는 상황이 발생하는 경우가 있습니다.이 경우 되돌아오는 전자 메일 주소를 반드시 제거해야 합니다.

소프트 바운스

부드러운 바운스는 일시적인 것이다.소프트 바운스가 발생한 바운스된 메시지는 다음 시간에 ^[5]재발송을 시도할 수 있습니다.소프트 바운스는, 전자 메일의 수신자가 완전한 수신 트레이를 가지고 있기 때문에, 다른 전자 메일을 격납할 공간이 없거나, 수신할 수 있는 전자 메일의 사이즈에 제한이 있는 경우에 발생합니다.소프트 바운스가 표시되는 기타 상황은 특정 발신인을 '스팸' 발신인으로 표시하거나 특정 발신인을 블랙리스트에 올리기 위해 수신인의 전자 메일에 설정된 블록입니다.또, 수신자의 이메일이 일시적으로 정지되거나 서버의 일시적인 에러가 발생하는 것도 소프트 바운스의 원인입니다.

배달 오류

메일 배달의 여러 위치에서 오류가 발생할 수 있습니다.발신인은 메시지를 발송할 수 없었다고 보고하는 메일 서버 또는 메시지를 수신했지만 지정된 사용자에게 배달할 수 없다고 보고하는 수신인의 메일 서버로부터 바운스 메시지를 수신할 수 있습니다.서버가 배달 메시지를 수락할 때 배달이 실패했을 때 바운스 메시지를 배달할 책임도 수락합니다.

디스크 공간 부족으로 인한 바운스

전자 메일이 수신처 서버에 수신되어 주소가 지정되었을 때(예를 들면, mymail.example로 송신할 때 등), 서버의 기반이 되는 하드 드라이브에 충분한 공간이 없는 경우, 메일 데몬이 지정된 사용자의 우편함에 메시지를 보관하지 못할 수 있습니다.

도달할 수 없는 대상으로 인한 바운스

전자 메일을 송신할 때, 전자 메일의 송신원서비스가 수신처 주소에 도달할 수 없는 경우가 있습니다.이 경우, 발신인은 자신의 메일 서버로부터 바운스 메시지를 수신합니다.메일 서버가 대상에 도달할 수 없는 일반적인 원인:

• 대상 주소를 확인할 수 없습니다.예를 들어 도메인 이름이 존재하지 않는 경우.
• 대상 주소로 연결을 설정할 수 없습니다.예를 들어 서버에 IP 주소가 할당되지 않았거나 서버가 오프라인인 경우입니다.

위조 메시지에서 바운스

사용자가 실제로 발송하지 않은 메시지에 대한 잘못된 바운스메시지를 수신할 수 있습니다.이 문제는 특히 스팸 발송자(발신자)가 다른 사용자(스팸의 의도된 수신자)에게 메시지를 위조하여 다른 사용자(서드파티)로부터 메시지를 표시하도록 위조하는 전자 메일 스팸 또는 전자 메일 바이러스의 컨텍스트에서 발생할 수 있습니다.메시지를 목적의 수신자에게 전달할 수 없는 경우 바운스메시지는 스팸 발송자가 아닌 서드파티에 "반환"됩니다.이것은 후방 산란이라고 불립니다.

기타 원인

library.example 메일서버가 메시지를 배달할 수 없음을 알고 있는 경우(예를 들어 Jill이 사용자 계정을 가지고 있지 않은 경우 등), 처음부터 메시지를 받아들이지 않기 때문에 바운스를 보내지 않습니다.대신 SMTP 오류 코드가 포함된 메시지를 거부합니다.이로 인해 Jack의 메일 서버(예: store.example)는 바운스를 작성 및 제공해야 합니다.

용어.

바운스는 자동응답자의 특별한 형태입니다.자동응답(자동응답)은 수신한 메일에 대한 응답으로 프로그램이 인간 사용자가 아닌 바운스주소로 송신하는 메일입니다.

기타 자동 응답의 예로는 휴가 메일, 챌린지 응답 스팸필터링 문제, 목록 서버로부터의 응답, 피드백 보고서 등이 있습니다.기타 자동 응답에 대해서는 RFC 3834에서 설명하고 있습니다.자동 응답은 에 송신됩니다.Return-Path자동 회신을 트리거한 수신 메일에 기재되어 있습니다.이 응답은 일반적으로 빈 리턴 패스와 함께 송신됩니다.그렇지 않으면 자동 응답기가 자동 회신을 ^{[citation needed]}주고받을 때 갇힐 수중에 갇힐 수 있습니다.

그Return-Path배달된 메일에서 헤더 필드로 표시됨Return-PathSMTP Mail Delivery Agent(MDA; 메일 배달 에이전트)에 의해 삽입됩니다(일반적으로 MTA(메일 전송 에이전트)와 결합됩니다).MDA는 SMTP에 리버스 경로를 복사하기만 하면 됩니다.MAIL FROM에 명령하다.Return-PathMDA는 가짜도 제거합니다.Return-Path다른 MTA에 의해 삽입된 헤더필드.이 헤더필드는 일반적으로 에서 볼 수 있는 마지막 리버스 패스를 반영합니다.MAIL FROM명령어를 입력합니다.

현재는, 낡은 SMTP 「소스 라우팅」이 1989년에 폐지되었기 때문에, 통상의 E-메일 주소로 축소되고 있습니다.이력의 배경 정보에 대해서는, 송신자 리라이트 스킴을 참조해 주세요.경로의 특수한 형식인 빈 경로가 아직 존재합니다.MAIL FROM:<>많은 자동 응답, 특히 모든 바운스에 사용됩니다.

엄밀한 의미에서는 빈칸이 아닌 바운스(bounces)와 함께 전송된다.Return-Path틀렸습니다.RFC 3834는 로컬 부분('@' 앞의 왼쪽)에 근거해 잘못된 바운스를 특정하기 위한 휴리스틱스를 제공하고 있습니다.Return-Path메일 헤더 필드도 정의합니다.Auto-Submitted, 자동 응답을 식별합니다.그러나 메일 헤더는 메일 데이터의 일부입니다(SMTP 명령).DATA) 및 MTA는 일반적으로 메일을 확인하지 않습니다.그들은 봉투를 다루는데, 그 봉투에는MAIL FROM주소(일명.k.a)Return-Path,Envelope-FROM(또는 "리버스 패스") 단, RFC 2822- 등에서는 제외됩니다.From메일 머리글 필드에From이러한 세부 사항은 BATV와 같은 스킴에서 중요합니다.

나머지는 빈칸과 함께 튀어오른다.Return-Path는 Non-Delivery Report(NDR; 비배달 보고서) 또는 Delivery Status Notification(DSN; 배달 상태 알림)입니다.DSN은 SMTP 서비스 확장을 사용하여 명시적으로 요청할 수 있지만 널리 사용되지 않습니다.배달 실패 상세에 대한 명시적 요구는 Variable Envelope Return Path(VERP; 가변 인베로프 리턴 경로)를 사용하여 훨씬 일반적으로 구현되지만, 이러한 명시적 요구는 ^[6]거의 구현되지 않습니다.

NDR은 기본적인 SMTP 기능입니다.MTA는 전달 또는 전달을 위해 메일을 수락하면 즉시 메일을 자동으로 삭제(폐기)할 수 없습니다. 전달 또는 전달에 실패한 경우 반송 메시지를 작성하여 발신자에게 발송해야 합니다.

바운싱 vs.

MDA를 제외한 모든 MTA는 다른 MTA로 메일을 전송합니다.다음 MTA는 "사용자 알 수 없음", "할당량 초과" 등과 같은 SMTP 오류 메시지가 포함된 메일을 자유롭게 거부할 수 있습니다.이 시점에서 송신 MTA는 메시지를 바운스해야 합니다.즉, 발신자에게 통지합니다.또한 MTA를 거부하지 않거나 RFC 5321에 따라 바운스가 발생할 수 있습니다.

"SMTP 서버가 메일 릴레이 작업을 수락하고 나중에 수신처가 잘못되었거나 다른 이유로 메일을 배달할 수 없음을 알게 되면, "배달할 수 없는 메일" 알림 메시지를 작성하여 배달할 수 없는 메일의 발신자에게 전송해야 합니다(역경로로 표시됨).

이 규칙은 SMTP에 필수적입니다.이 규칙은 이름에서 알 수 있듯이 '간단한' 프로토콜이기 때문에 블랙홀에서 메일이 자동으로 사라지면 안정적으로 작동할 수 없기 때문에 문제를 발견하고 수정하기 위해 바운스가 필요합니다.

메시지 사일런트 드롭

그러나 오늘날에는 대부분 스팸 메일을 수신할 수 있으며, 이는 보통 위조된 이메일을 사용합니다.Return-Paths. 그러면 MTA가 발신자에게 통지하고 위조품에 바운스를 보내는 것이 불가능할 수 있습니다.Return-Path무고한 제3자를 때릴 수도 있어요또한 메시지를 거부하기보다(바운스는커녕) 사일런트드롭을 권장하는 구체적인 이유가 있습니다.

• 경험적으로 필터링된 스팸.스팸 필터는 완벽하지 않습니다.콘텐츠 필터링을 기반으로 스팸을 거부하는 것은 스팸 발송자가 필터를 통과하는 콘텐츠를 찾을 때까지 여러 가지 대안을 시도할 수 있는 테스트 환경을 제공한다는 것을 의미합니다.
• 바이러스와 웜.대부분의 경우 감염된 기계에서 자동으로 전송됩니다.바운스는 웜 자체의 복사본을 포함할 수 있기 때문에 웜 확산의 원인이 될 수 있습니다.

RFC 5321, 섹션 6.2를 다시 인용합니다.

아래 섹션 7.8과 섹션 7.9에서 설명한 바와 같이 발송인의 통지 없이 메일을 투하하는 것은 실제로 허용됩니다.하지만, 이것은 매우 위험하고 우편물이 배달되거나 반송된다는 오랜 전통과 지역사회의 기대에 위배된다.사일런트 메시지 드롭이 잘못되면 인터넷 메일 시스템의 신뢰성에 대한 신뢰가 쉽게 떨어질 수 있습니다.따라서 메시지 무음 폐기는 메시지가 심각하게 부정적이거나 부적절하다는 신뢰도가 매우 높은 경우에만 고려되어야 합니다."

송신자의 유효성을 검사하지 않는 것은, 이전에 언급한 폐지된 송신원경로가 없는 현재의 SMTP 에 내재하는 결함입니다.이것은 다양한 제안, 특히 BATV와 SPF에 의해 직접적으로 해결된다.

바운스 메시지의 원인

이메일이 되돌아오는 이유는 여러 가지가 있습니다.수신자 주소의 철자가 틀렸거나 단순히 수신 시스템에 존재하지 않는 것이 원인 중 하나입니다.이것은 사용자가 알 수 없는 상태입니다.다른 이유로는 전체 Disk와 같은 리소스 소진이나 스팸 필터로 인한 메시지 거부 등이 있습니다.또한 사용자가 온 ^[7]디맨드로 메시지를 "바운스"할 수 있는 MUA도 있습니다.사용자가 시작한 이러한 바운스는 가짜 바운스입니다.정의상 실제 바운스는 자동화되며 MTA 또는 MDA에 의해 방출됩니다.

SMTP 의 바운스 메세지는, 봉투의 송신원주소로 송신됩니다.<>는, 늘 송신원주소로 알려져 있습니다.그것들은 자주 와 함께 보내집니다.From:헤더 어드레스MAILER-DAEMON수신자 사이트에서 참조할 수 있습니다.

통상, 바운스 메시지에는, 원래의 송신자가 메세지가 전달되지 않은 이유를 이해하는 데 도움이 되는 몇개의 정보가 포함됩니다.

• 메시지가 되돌아온 날짜와 시간,
• 반송된 메일 서버의 ID,
• 파일이 되돌아온 이유(예: 사용자를 알 수 없거나 편지함이 가득 찬 경우),
• 되돌아온 메시지의 헤더 및
• 반송된 메시지의 일부 또는 전체 내용.

RFC 3463에서는 바운스 이유를 나타내기 위해 사용되는 코드를 설명하고 있습니다.공통 코드는 5.1.1(알 수 없는 사용자), 5.2.2(메일함 가득) 및 5.7.1(보안 정책/메일 필터에 의해 거부됨)입니다.

포맷

Reject에 관여하는 MTA는 Reporting MTA의 관점에 따라 이름이 지정됩니다.MTA 이름은 종종 dns 유형입니다.

관리 메시지 보고서 형식은 다음과 같이 정의됩니다. RFC6522.DSN은 다음 세 부분으로 구성된 MIME 멀티파트/리포트 메시지입니다.

1. 사람이 읽을 수 있는 설명
2. 기계 구문 분석 가능한 메시지/배송 상태, 가능한 여러 필드를 나타내는 "name: type; value" 행 목록
3. 원래 메시지 또는 그 일부(type message/timeout822)의 엔티티로서의 메시지.

DSN의 두 번째 부분도 읽을 수 있습니다.어떤 MTA가 어떤 역할을 했는지 이해하는 것이 중요합니다.Reporting-MTA는 DSN의 작성과 송신을 담당합니다.

SMTP 트랜잭션 중에 Remote-MTA가 메시지를 거부하면 Diagnostic-Code of type smtp 필드를 사용하여 해당 값을 보고할 수 있습니다.SMTP 응답에는, 3 자리수의 수치 외에, 사람이 판독 가능한 부분이 포함되어 있는 것에 주의해 주세요.정보

Remote-MTA: dns; smtp.store.example [ 192 . 0 . 2 . 3 ]진단 코드: smtp; 550 이러한 사용자는 여기에 없습니다.

다음과 같이 보고되는 경우가 있습니다.

smtp.store.example [ 192 . 0 . 2 . 3 ]>> RCPT TO : < nonexisting user @store . example >< 550 이러한 사용자는 여기에 없습니다.

보안에 관한 영향

호주 보안 연구자(Sebastian Salla)는 2021년 10월 4일 이메일 바운스 메시지를 악용하여 이메일 스팸 및 멀웨어 필터의 운영 효율성을 줄이는 방법을 시연했습니다.많은 전자 메일 게이트웨이의 기본 동작은 바운스 메시지에 변조되지 않은 인바운드 메시지 머리글 복사본을 포함합니다.이러한 메시지 헤더를 분석함으로써 위협 행위자는 이메일이 대상 ^[8]우편함에 도착하는지 여부를 명확하게 식별할 수 있습니다.이 공격은 수십 개의 취약한 대상을 포함하도록 확장되어 피싱 ^[9]캠페인의 효율성을 향상시킬 수 있습니다.

「 」를 참조해 주세요.

• 백스캐터(이메일 스팸 백스캐터)
• 바운스 주소 태그 검증(BATV)
• 이메일 추적
• 송신자 정책 프레임워크(SPF)
• 도메인 키 식별 메일(DKIM)
• 송신자 개서 방식(SRS)
• SMTP(Simple Mail Transfer Protocol)
• Variable Envelope Return Path(VERP)

관련 RFC

• RFC 5321 - 간이 메일 전송 프로토콜
• RFC 3461 - 배달 상태 알림(DSN)을 위한 SMTP(Simple Mail Transfer Protocol) 서비스 확장
• RFC 6522 - 메일시스템 관리 메시지 보고서용 멀티파트/리포트 미디어 유형
• RFC 3463 - SMTP 확장 상태 코드
• RFC 3464 - 배달 상태 알림을 위한 확장 가능한 메시지 형식
• RFC 3834 - 전자 메일에 대한 자동 응답에 관한 권장 사항
• RFC 5337 - 국제화 배송 상태 및 폐기 통지

레퍼런스

외부 링크

• 비배달 메시지를 통한 DDoS 공격 메일
• Exchange Server에서의 Microsoft DSN 및 NDR
• 바운스 이메일에 대해서