XIMS: Microsoft SMTP 서버가 타사 테스트에서 전자 메일 메시지를 받고 릴레이할 수 있다

기술 자료 번역 기술 자료 번역
기술 자료: 304897 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

현상

일부 타사 테스트를 사용하여 Microsoft Simple Mail Transfer Protocol(SMTP) 서버의 릴레이를 테스트하는 경우 SMTP 서버가 테스트에 실패하고 Microsoft SMTP 제품이 실제로는 그렇지 않은데도 릴레이를 위해 열리는 것처럼 보일 수 있습니다.

SMTP 서버의 릴레이를 테스트하는 데 사용할 수 있는 일반적인 테스트가 있습니다. 다음과 같은 타사 웹 사이트 및 도구를 사용할 수 있습니다.
http://www.abuse.net/relay.html
http://mail-abuse.net
이 문서에 포함된 다른 공급업체의 연락처 정보는 기술 지원을 받는 데 도움을 주기 위한 것입니다. 이 연락처 정보는 예고 없이 변경될 수 있습니다. Microsoft는 이러한 다른 공급업체 연락처 정보의 정확성을 보증하지 않습니다.

먼저 SMTP 서버가 이러한 테스트 중 일부에서 실패할 수 있으며 Microsoft SMTP 제품이 릴레이를 위해 열리는 것처럼 보일 수 있습니다. 그러나 서버를 면밀히 검토하고 나면 Microsoft SMTP 제품이 릴레이를 위해 열리는 것이 아니라는 것을 알게 됩니다.

원인

SMTP 프로토콜 통신의 모든 받는 사람(TO) 또는 보낸 사람(FROM) 주소는 로컬 부분(또는 사서함) 및 도메인 부분의 두 부분으로 구성되어 있습니다. 도메인 부분(즉, 기호[@] 바로 다음에 나오는 부분)을 지정하지 않으면 전자 메일 메시지는 로컬로 간주됩니다. 사실, 일부 Microsoft SMTP 제품은 일부 사용자가 전자 메일 주소로 사용자 이름만 사용하도록 해당 SMTP 클라이언트를 구성하기 때문에 로컬 도메인을 추가합니다. 기본 로컬 도메인을 추가함으로써 Microsoft 서버는 가장 기본값에 가까운 값을 추가하여 지원 비용을 절감할 수 있습니다.

이 문제는 Microsoft SMTP 제품이 배달할 SMTP 전자 메일 메시지를 받아들이기 전에 디렉터리 조회를 수행하지 않기 때문에 발생합니다. Microsoft SMTP 제품은 도메인이 로컬인지 또는 명시적으로 허용되는 도메인인지 확인하기 위해 받는 사람의 도메인만 검사합니다. 받는 사람의 도메인이 로컬이나 허용되는 도메인이 아닌 경우 서버는 다음과 비슷한 오류 메시지로 응답합니다.
550 5.7.1 Relaying prohibited
릴레이를 방지하는 데 필요한 것은 받는 사람 주소의 도메인 부분이 로컬인지 확인하는 것이 전부입니다. 받는 사람이 유효한지 확인하기 위해 메일 서버의 디렉터리를 검사하는 것은 옵션이며 필수 사항은 아닙니다. 메일 서버가 메시지를 받아들인 다음 나중에 메시지를 배달할 수 없다고 결정하는 경우 서버는 배달 못함 보고서(NDR)를 생성해야 합니다. RFC(Request for Comments) 2821 문서 3.7 절 및 RFC 1123 문서 5.2.7 절을 참조하십시오. Microsoft SMTP 제품은 이 요구 사항을 준수합니다. Microsoft SMTP 서버는 릴레이를 위해 메시지를 받아들이는 것처럼 보이지만 나중에 서버가 메시지를 배달하지 않고 NDR을 생성합니다.

추가 정보

SMTP 프로토콜 통신 중에 디렉터리 조회를 수행하는 기능이 필요한 경우 Windows 2000 SMTP 프로토콜 이벤트 싱크를 작성하면 됩니다.

자세한 내용은 다음 MSDN Platform SDK SMTP 서버 이벤트 웹 사이트를 참조하십시오.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/smtpevt/html/_smtpevt_protocol_event_interfaces.asp
권장하는 RFC 준수 응답은 다음과 유사합니다.
550 5.1.1 user@northwindtraders.com... User unknown
Microsoft는 다음과 같은 이유로 SMTP 프로토콜 통신 중에 디렉터리 조회를 수행하지 않기로 결정했습니다.
  • 가짜 사용자에 5xx 오류를 반환하면 서버에 다량의 원하지 않는 광고용 전자 메일 메시지(스팸 또는 UCE)를 보내는 사용자는 어느 주소가 진짜이고 어느 주소가 가짜인지 즉시 알게 됩니다. 이 사용자가 SMTP 프로토콜을 통해 이름 사전을 사용할 경우 해당 사용자는 유효한 전자 메일 주소 목록을 쉽게 얻을 수 있습니다. 따라서 사용자 이름이 전자 메일 주소와 같은 경우가 종종 있기 때문에 로컬 사용자에게 보안 위험이 생길 수도 있습니다.
  • 악의 있는 사용자가 보낸 사람 주소를 사용하여 시스템에 승인 없이 액세스한 다음 희생되는 서버를 사용하여 실제 받는 사람에게 NDR을 보낼 수 있습니다. 이 공격은 침입자가 보내는 만큼의 데이터를 사용하여 이 서버에서만 발생합니다. 즉, 악의 있는 사용자가 1MB의 데이터를 제3자에 보내려는 경우 1MB의 데이터를 SMTP 서버로 보내기 위해 자신의 대역폭 1MB를 사용해야 합니다. 일반적으로 악의 있는 사용자는 1MB의 데이터를 보내려고 하지만 인터넷을 통해 수십 또는 수백 MB의 데이터가 하나 또는 여러 희생자에게 전달됩니다. 이 문제를 예방하는 가장 좋은 방법은 모든 인터넷에서 보낸 사람 주소의 유효성을 검사하는 것입니다. 그러나 인터넷에서 보낸 사람 주소의 유효성을 검사하는 표준은 없으므로 이 문제를 처리하는 가장 좋은 방법은 메시지 머리글을 검사하는 것입니다.
  • SMTP 프로토콜 통신 중에 디렉터리 조회를 수행하는 경우 SMTP 프로토콜이 훨씬 느려질 수 있습니다. 본 문서를 게시할 당시에 Microsoft는 인터넷 또는 데스크톱 SMTP 클라이언트에서 SMTP 메시지가 차단되는 것을 방지할 만큼 SMTP 서버가 빨라야 한다는 전제 하에 작업 중입니다. 디렉터리가 오버로드되면 서버가 너무 느려져 클라이언트에 오류 메시지가 나타날 수 있습니다. 일부 상황에서는 디렉터리를 사용할 수 없거나 특정 도메인의 릴레이가 필수적일 수 있지만 ISP 호스팅과 같은 환경에서 디렉터리의 복사본을 사용하지 못할 수 있습니다.

일반 릴레이 정보

릴레이는 SMTP 클라이언트가 SMTP 서버를 사용하여 원격(비로컬) 도메인에 전자 메일 메시지를 전달할 수 있는 상황입니다. 릴레이는 SMTP가 이 목적으로 설계되었기 때문에 본질적으로 나쁜 것은 아닙니다. RFC 2821 문서 2.1 및 3.7 절을 참조하십시오.

그러나 릴레이가 제어되지 않는 경우(제어되지 않는 호스트를 "오픈 릴레이" 호스트라 함) 악의 있는 사용자가 릴레이를 사용하여 다량의 원하지 않는 광고용 전자 메일 메시지(스팸 또는 UCE)를 보낼 수 있습니다. 이러한 원하지 않는 전자 메일 메시지를 중간 호스트에서 바운스하여 악의 있는 사용자가 자신의 ID를 알기 어렵게 합니다. 또한 릴레이 호스트의 리소스가 묶이게 되어 릴레이 호스트가 유효한 전자 메일 메시지를 보내지 못할 수도 있습니다. 특히 이러한 원하지 않는 전자 메일 메시지를 보내는 대부분의 사용자는 자신의 대역폭을 사용하지 않고 수많은 받는 사람들에게 단일 메시지를 보낼 수 있습니다.

릴레이 테스트 1

이것은 SMTP 릴레이의 표준 테스트입니다. 관리자가 특별히 허용하지 않거나 클라이언트가 먼저 승인하지 않는 경우 SMTP 클라이언트에게 이런 식의 릴레이가 허용되서는 안됩니다.
>>> RSET 
<<< 250 2.0.0 Resetting 
>>> MAIL FROM:<spamtest@contoso.net> 
<<< 250 2.1.0 spamtest@contoso.net....Sender OK 
>>> RCPT TO:<relaytest@contoso.net> 
<<< 550 5.7.1 Unable to relay for relaytest@contoso.net

릴레이 테스트 2

이것은 기본적으로 같은 테스트지만 보낸 사람이 원격 도메인의 사용자가 아닌 로컬 사용자입니다. 시스템에 승인 없이 액세스하는 데 받는 사람 주소가 주로 사용되기 때문에 서버는 이것에 속아서는 안됩니다.
>>> RSET 
<<< 250 2.0.0 Resetting 
>>> MAIL FROM:<spamtest> 
<<< 250 2.1.0 spamtest@northwindtraders.com....Sender OK 
>>> RCPT TO:<relaytest@contoso.net> 
<<< 550 5.7.1 Unable to relay for relaytest@contoso.net

릴레이 테스트 3

이 테스트는 보낸 사람 주소가 NULL이거나 비어 있는 경우입니다. NDR 및 기타 알림에 NULL 보낸 사람 주소가 있습니다. 그러나 보낸 사람 주소의 도메인이 로컬 도메인이 아니면 알림을 통과해서는 안됩니다.
>>> RSET 
<<< 250 2.0.0 Resetting 
>>> MAIL FROM:<>
<<< 250 2.1.0 <>....Sender OK 
>>> RCPT TO:<relaytest@contoso.net> 
<<< 550 5.7.1 Unable to relay for relaytest@contoso.net

릴레이 테스트 4

이 테스트는 릴레이 테스트 2와 같지만 클라이언트가 로컬 도메인을 명시적으로 추가했습니다. SMTP 서버는 이것에 속아서는 안됩니다.
>>> RSET 
<<< 250 2.0.0 Resetting 
>>> MAIL FROM:<spamtest@northwindtraders.com> 
<<< 250 2.1.0 spamtest@northwindtraders.com....Sender OK 
>>> RCPT TO:<relaytest@contoso.net> 
<<< 550 5.7.1 Unable to relay for relaytest@contoso.net

릴레이 테스트 5

이 테스트도 릴레이 테스트 2와 같지만 서버를 속이려고 서버의 로컬 IP 주소가 추가되었습니다. 일반적으로 이러한 형식의 주소는 허용되지만 서버는 원격 도메인에 대한 릴레이를 허용해서는 안됩니다. 보낸 사람 주소에 "localhost" 또는 서버의 DNS(Domain Name System) 이름을 사용하는 여러 테스트에서 서버는 보낸 사람 주소에 속아서는 안됩니다.
>>> RSET 
<<< 250 2.0.0 Resetting 
>>> MAIL FROM:<spamtest@[10.10.10.10]> 
<<< 250 2.1.0 spamtest@[10.10.10.10]....Sender OK 
>>> RCPT TO:<relaytest@contoso.net> 
<<< 550 5.7.1 Unable to relay for relaytest@contoso.net

릴레이 테스트 6

이 테스트는 특히 로컬 도메인을 추가하고 at 기호(@)를 백분율 기호(%)로 변경하여 전자 메일 메시지를 라우팅하는 오래된 UNIX 기반 서버를 위한 것입니다. 그러면 서버는 메일을 릴레이합니다. 이 Microsoft 제품은 메일을 받고 테스트에 실패하게 됩니다. 백분율 기호(%)는 로컬 부분에 유효한 문자이기 때문에 이 제품은 메시지를 받고 디렉터리 조회에 실패하는 경우 NDR을 보내도록 선택합니다. Microsoft SMTP 제품은 메시지가 전달되지 않고 NDR을 보내기 때문에 이러한 종류의 릴레이에 취약하지 않습니다.
>>> RSET 
<<< 250 2.0.0 Resetting 
>>> MAIL FROM:<spamtest> 
<<< 250 2.1.0 spamtest@northwindtraders.com....Sender OK 
>>> RCPT TO:<relaytest%contoso.net> 
<<< 250 2.1.5 relaytest%contoso.net@northwindtraders.com

릴레이 테스트 7

이것은 릴레이 테스트 6의 또 다른 변형입니다. 이 Microsoft 제품은 메일을 받고 테스트에 실패하게 됩니다. 인용 부호 문자(")는 로컬 부분에 유효한 문자이기 때문에 이 제품은 메시지를 받고 디렉터리 조회에 실패하는 경우 NDR을 보내도록 선택합니다. Microsoft SMTP 제품은 메시지가 전달되지 않고 NDR을 보내기 때문에 이러한 종류의 릴레이에 취약하지 않습니다.
>>> mail from: <spamtest> 
<<< 250 2.1.0 spamtest@northwindtraders....Sender OK 
>>> rcpt to: <"nobody@mail-contoso.org"> 
<<< 250 2.1.5 "nobody@mail-contoso.org"@northwindtraders.com
SMTP 서버가 이러한 테스트 중 하나 이상에 실패하는 경우(특히 릴레이 테스트 6과 7) 서버가 오픈 릴레이라는 의미일 수도 있고 그렇지 않을 수도 있습니다. Microsoft Exchange 및 Microsoft Windows 2000 SMTP를 비롯한 일부 시스템은 릴레이 메일을 받지만 메일을 배달하는 대신 내부적으로 메시지를 거부합니다. 그러나 실제 테스트 메시지를 보내지 않고는 서버가 실제로 오픈 릴레이인지 여부를 확실하게 판단할 수 없습니다.

Exchange 2000 서버에 대해 릴레이 테스트 6과 7을 실행하면 테스트가 잘못된 받는 사람에 대해 메시지를 생성하기 때문에 Messages 탭의 Forward all mail with unresolved recipients to host 상자에 있는 기본 SMTP 가상 서버의 속성에서 Exchange System Manager에 지정된 사서함에 다음과 비슷한 NDR이 수신됩니다.
받는 사람의 일부 또는 전부가 메시지를 받지 못했습니다. 
 
제목: Relay Test 6 
보낸 날짜: 2002-03-22 17:47
 
다음 받는 사람에게 도착하지 않았습니다. 
 
relaytest%contoso.net@northwindtraders.com on 2002-03-12 12:30 
이 메시지가 보내진 조직에 해당 전자 메일 계정이 없습니다. 전자 메일 주소를 확인하거나 받는 사람에게 직접 문의하여 정확한 전자 메일 주소를 알아내십시오. 
<server.northwindtraders.com #5.1.1>
또는

받는 사람의 일부 또는 전부가 메시지를 받지 못했습니다. 
 
제목: Relay Test 7 
보낸 날짜: 2002-03-13 12:30 
 
다음 받는 사람에게 도착하지 않았습니다. 
 
"nobody@mail-contoso.org"@northwindtraders.com on 2002-03-13 12:30 
이 메시지가 보내진 조직에 해당 전자 메일 계정이 없습니다.  전자 메일 주소를 확인하거나 받는 사람에게 직접 문의하여 정확한 전자 메일 주소를 알아내십시오. 
<server.northwindtraders.com #5.1.1>
이러한 NDR을 사용하여 메시지가 릴레이되지 않은 것을 입증할 수 있습니다.

Exchange Server 5.5를 실행 중이고 오픈 릴레이로부터 서버를 보호해야 하는 경우 수행할 조치에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
196626 XFOR: 인터넷 메일 서비스에서 라우팅 제한
Microsoft Exchange 2000을 실행 중인 경우 기본적으로 릴레이하려면 인증이 필요합니다. 자세한 내용은 Exchange 2000 도움말을 참조하십시오.



Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.

속성

기술 자료: 304897 - 마지막 검토: 2006년 11월 20일 월요일 - 수정: 3.1
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Windows XP Professional
키워드:?
kbprb KB304897

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com