콜백 검증

콜백 검증(Callout Verification) 또는 발신자 주소 검증(Sender Address Verification)이라고도 하는 콜백 검증(Callback Verification)은 SMTP 소프트웨어가 전자우편 주소의 유효성을 확인하기 위해 사용하는 기법이다.가장 일반적인 확인 대상은 메시지 봉투의 발신인 주소(SMTP 대화 중에 "MAIL FROM"으로 지정한 주소)이다.주로 안티스팸 대책으로 쓰인다.

목적

전자우편 스팸의 상당 부분이 위조된 발신인("mfrom") 주소에서^{[citation needed]} 생성되기 때문에 이 방법을 사용하여 위조된 주소가 잘못된 것인지 여부를 확인함으로써 일부 스팸을 탐지할 수 있다.

관련 기법은 "call forwards"로, 2차 또는 방화벽 메일 교환기가 주소의 배달 가능 여부를 결정하기 위해 도메인의 1차 메일 교환기에서 수신자를 확인할 수 있다.

과정

수신 메일 서버는 발신인 주소의 두 부분, 즉 도메인 이름(@ 문자 뒤의 부분)과 로컬 부분(@ 문자 이전의 부분)을 모두 확인하여 발신인 주소를 확인한다.첫 번째 단계는 발신인 주소의 메일 교환기에 대한 SMTP 연결을 성공적으로 설정하는 것이다.메일 교환기는 도메인의 DNS 영역에서 MX 레코드를 조회하면 찾을 수 있다.두 번째 단계는 교환기를 질의하고 주소를 유효한 주소로 수락하는지 확인하는 것이다.이것은 주소로 이메일을 보내는 것과 같은 방법으로 이루어지지만, 메일 교환기가 수신인 주소를 받아들이거나 거부하면 프로세스가 중지된다.이러한 단계는 수신 메일 서버가 메일을 발신인에게 반송하기 위해 수행되는 단계와 동일하지만, 이 경우 메일이 발송되지 않는다.발송된 SMTP 명령은 다음과 같다.

헬로verifier host name보낸 사람:[] RCPT에서:[]로 메일the address to be tested> STOP

마찬가지로 MAIL FROM 및 RCPT TO 명령은 VRFY 명령으로 대체될 수 있지만, VRFY 명령은 지원될 필요가 없으며 일반적으로 현대 MTA에서는 비활성화된다.

이 두 기법은 모두 관련 SMTP RFC(RFC 5321)를 기술적으로 준수하지만, RFC 2505(최상의 현재 관행)는 기본적으로 디렉토리 수집 공격을 방지하기 위해 VRFY 명령을 비활성화할 것을 권장한다.(한 가지 광범위한 해석은 MAIL FROM/RCPT to TO 명령 쌍도 같은 방식으로 대응해야 한다는 것을 의미하지만, 이 I는 I.s RFC에 의해 명시되지 않음)

단점들

콜백 검증은 남용적이며^[1] 서버, 도메인 또는 IP 블록의 차단 목록으로 이어질 수 있다.

메일 서버의 관리자가 VRFY를 비활성화한 경우, RCPT TO를 무단 액세스 및 액세스 제어 회피 시도 방법으로 사용하십시오.이처럼 운영자는 관할구역에 따라 민·형사상 고발에 취약하다.

제한 사항

사후 수정과 사후 수정 모두를 위한 문서에는 이 기법의 사용에^[2][3] 대한 주의사항이 수록되어 있으며 SMTP 콜백에 대한 많은 제한사항이 언급되어 있다.특히 실효성이 없거나 콜백을 받는 시스템에 문제를 일으키는 상황이 많다.

• 일부 일반 메일 교환기는 콜백에 유용한 결과를 제공하지 않는다.
  • 모든 바운스 메일을 거부하는 서버(STD 3의^[4] 일부인 RFC 1123과 대조됨).예를 들어, 이 문제를 해결하기 위해, 포스트픽스는 콜아웃의 MAIL FROM에 있는 로컬 포스트마스터 주소 또는 "이중 바운스" 주소를 사용한다.그러나 이 해결책에는 두 가지 문제가 있다. 첫째, 검증 루프를 유발할 수 있다. 둘째, 백스캐터를 줄이기 위해 바운스 주소 태그 검증을 사용하면 실패한다.^[1]따라서, 이 작업은 사용되어서는 안 된다.콜백 검증은 이전의 MAIL FROM 단계 대신 DATA 단계에서 모든 바운스 거부가 발생할 경우 계속 작동할 수 있으며, 잘못된 이메일 주소는 DATA 단계로 이동하지 않고 RCPT TO 단계에 남아 있다.^[2][3]
  • RCPT TO 단계에서 모든 전자우편 주소를 승인하지만 DATA 단계에서 잘못된 전자우편 주소를 거부하는 서버.이는 일반적으로 디렉터리 수집 공격과 의지로 인해 전자 메일 주소가 유효한지 여부에 대한 정보를 제공하지 않기 때문에 콜백 확인이 작동하지 않도록 하기 위해 이루어진다.^[2][1]
  • SMTP 대화 중에 모든 메일을 수신하고 나중에 자체 바운스를 생성하는 서버.^[2]이 문제는 원하는 주소뿐만 아니라 임의의 존재하지 않는 주소를 시험함으로써 완화될 수 있다(시험에 성공하면 추가 검증은 무용지물이다).
  • 캐치-매치-메일(catch-all e-mail)을 구현하는 서버는 정의상 모든 전자메일 주소를 유효하다고 간주하고 이를 수용한다.수용 후 바운스하는 시스템과 마찬가지로, 무작위 존재하지 않는 주소는 이것을 감지할 수 있다.
• 콜백 프로세스는 주소가 확인되는 메일 서버가 "신중한 지연"(연결 지연의 원인) 및 그레이리스트링(확인 지연의 원인)을 포함한 느린 안티스팸 기술을 사용할 수 있기 때문에 배달 지연을 유발할 수 있다.^[2]
• 시스템이 그레이리스트링을 사용하기 위해 다시 호출되는 경우, 콜백은 그레이리스트링 시간이 만료될 때까지 유용한 정보를 반환하지 않을 수 있다.그레이리스트링은 익숙하지 않은 MAIL FROM/RCPT TO 이메일 주소 쌍을 볼 때 "임시 실패"(4xx 응답 코드)를 반환하는 방식으로 작동한다.그레이리스트 시스템은 RCPT TO에 대해 유효하지 않은 전자우편 주소를 부여했을 때 "영구적 오류"(5xx 응답 코드)를 줄 수 없으며, 대신 4xx 응답 코드를 계속 반환할 수 있다.^[5]
• 일부 전자우편은 합법적일 수 있지만 사용자 오류 또는 잘못된 구성으로 인해 유효한 "발굴된 원본" 주소가 없을 수 있다.검증 과정에서 통상 전면 거부가 발생하기 때문에 발신인이 스팸 발송자가 아닌 실수요자였다면 문제를 통보받을 수 있다는 긍정적인 측면이 있다.
• 서버가 많은 스팸을 수신하면 콜백을 많이 할 수 있다.만약 그 주소들이 유효하지 않거나 스팸메일 발송이라면, 서버는 주소를 수집하기 위해 사전 공격을 하는 스팸 발송자와 매우 유사하게 보일 것이다.이것은 결국 다른 곳에서 블랙리스트에 오를 수도 있다.^[2][1][6]
• 일부 관리자는 콜백 확인을 요청되지 않은 대량 전자우편(UBE)으로 간주하며, 원본 SMTP 클라이언트를 차단하거나 스팸으로 보고하거나, 백스캐터가 적은 경우에도 DNSBL에 추가할 수 있다.
• 모든 콜백은 시스템이 그 부담을 피할 수 있는 효과적인 방법을 거의 사용하지 않고, 시스템이 다시 호출되는 것에 대해 요청받지 않은 채 책임을 묻는다.극단적인 경우, 스팸 발송자가 동일한 발신인 주소를 남용하여 이 방법을 모두 사용하는 충분히 다양한 수신 MX 집합에서 이 주소를 사용하는 경우, 모두 콜백을 시도하여 위조 주소의 MX에 요청(효과적으로 분산 서비스 거부 공격)을 과부하할 수 있다.^[1]
• 스팸 발송자가 실제 전자 메일 주소를^[1][7] 스푸핑하거나 null 바운스 주소를 사용하면 콜백 검증에 영향을 미치지 않는다.

이러한 문제의 일부는 RFC의 한도를 위반하거나 확장하여 발생한다; 검증 문제는 의도하지 않게 사용된 잘못된 주소, null 보낸 사람의 거부 또는 그레이리스트링(예를 들어, 검증 받는 사람에 의해 발생하는 지연이 밀접하게 상대적인 경우)과 같은 이러한 문제를 송신자에게만 다시 반영한다.원인에 의해 야기되는 지연에 대한 에이드).많은 경우에서 이는 발생자 시스템이 문제를 감지하고 수정하는 데 도움이 된다(예: 의도치 않게 유효한 바운스를 받을 수 없는 경우).

위의 문제들 중 몇 가지는 검증 결과의 캐시에 의해 감소된다.특히, 유용한 정보를 제공하지 않는 시스템(RCPT TO 시간에 거부하지 않고, 모든 전자 메일을 수신하는 등)은 기억할 수 있으며, 그러한 시스템에 대한 향후 호출은 필요하지 않다.또한 특정 전자우편 주소에 대한 결과(긍정적 또는 부정적)도 기억될 수 있다.엑심과 같은 MTA는 캐싱이 내장되어 있다.^[3]

참조

외부 링크

• 스팸 링크: 발신자 콜아웃 확인
• 보낸 사람 확인 - 무료 소프트웨어 기반