Share via


Exchange Server 2003의 전송 및 메시지 흐름 기능

 

마지막으로 수정된 항목: 2006-05-02

Microsoft® Exchange Server 2003에서는 전송 및 메시지 흐름을 향상시키는 몇 가지 새로운 기능을 제공합니다. 이 항목에서는 다음 기능에 대해 설명합니다.

  • 향상된 연결 상태
    이 섹션에서는 향상된 연결 상태 기능이 Exchange 조직 전체에 복제되는 연결 상태 정보의 양을 줄이고 Exchange의 성능에 미치는 부정적인 영향을 감소시키는 방법에 대해 설명합니다.
  • 상호 포리스트 인증 구성
    Exchange 2003에서는 전자 메일 주소를 스푸핑하거나 위조할 수 없으므로 상호 포리스트 인증을 사용하려면 특정 구성 작업 단계를 수행해야 합니다. 이 섹션에서는 상호 포리스트 인증을 사용하는 방법에 대해 설명합니다.
  • 인터넷 메일 마법사
    Exchange 2003에서는 새로운 버전의 인터넷 메일 마법사를 사용하여 조직에서 인터넷 메일 배달을 단계적으로 구성할 수 있습니다. 이 섹션에서는 이 마법사를 사용하여 인터넷 메일 배달을 설정하는 방법에 대해 설명합니다.
  • 배달 상태 알림(DSN) 진단 로깅 및 코드
    Exchange 2003에서는 배달 상태 알림(DSN) 진단 로깅이 제공되고 몇 가지 새로운 DSN 코드가 구현되었습니다. 이 섹션에서는 DSN 진단 로깅을 구성하는 방법 및 Exchange 2003에서 사용할 수 있는 새 DSN 코드에 대해 설명합니다.
  • X.400(MTA) 및 SMTP 큐 디렉터리 이동 지원
    Exchange 2003에서는 Exchange System Manager를 사용하여 SMTP 및 X.400 큐 데이터의 저장 위치를 변경할 수 있습니다. 이 섹션에서는 Exchange System Manager를 사용하여 큐 디렉터리를 변경하는 방법에 대해 설명합니다.
  • 연결 필터링
    Exchange 2003에서는 차단 목록에 기반한 연결 필터링 기능을 사용할 수 있습니다. 이 섹션에서는 연결 필터링 작동 방법 및 Exchange 서버에 연결 필터링을 설정하는 방법에 대해 설명합니다.
  • 받는 사람 필터링
    Exchange 2003에서는 받는 사람 필터링을 사용하여 Microsoft Active Directory® 디렉터리 서비스에 포함되지 않은 사용자에게 보내진 전자 메일 메시지 또는 올바르게 정의된 받는 사람에게 보내진 원치 않는 상업성 전자 메일을 필터링할 수 있습니다.
  • SP2의 새로운 기능: 보낸 사람 ID 필터링
    Exchange Server 2003 SP2에서는 보낸 사람 ID 필터링 기능을 사용할 수 있습니다. 보낸 사람 ID는 더 효과적으로 UCE(원치 않는 상업성 전자 메일)와 피싱 사기를 방지하는 데 사용할 수 있는 전자 메일 업계의 표준 기능입니다. 특히 보낸 사람 ID는 도메인 스푸핑도 방지할 수 있습니다.
  • SP2의 새로운 기능: 지능형 메시지 필터링
    Exchange Server 2003 SP2를 설치할 때 지능형 메시지 필터링도 자동으로 설치됩니다.
  • 필터 적용 방법
    이 섹션에서는 SMTP 세션 동안 필터 및 제한 사항이 적용되는 방법에 대해 설명합니다.
  • SMTP 가상 서버로의 전송 제한 기능 향상
    이 섹션에서는 Exchange 2003의 보안 그룹을 기준으로 전송을 제한하는 방법에 대해 설명합니다.
  • SMTP 가상 서버로의 릴레이 제한 기능 향상
    이 섹션에서는 Exchange 2003의 보안 그룹을 기준으로 릴레이를 제한하는 방법에 대해 설명합니다.

Exchange 2003에서는 전송 및 메일 흐름을 향상시키기 위해 다음과 같은 기능도 제공합니다.

  • 새로운 메일 그룹 유형인 쿼리 기반 메일 그룹을 사용하면 LDAP 쿼리를 사용하여 메일 그룹의 구성원을 동적으로 지정할 수 있습니다. 자세한 내용은 Exchange Server 2003 관리 기능에서 “쿼리 기반 메일 그룹” 및 “향상된 메시지 추적”을 참조하십시오.
  • 메일 그룹에 메일을 보낼 수 있는 사용자를 제한할 수 있습니다. 자세한 내용은 Exchange Server 2003 관리 기능에서 “사용자 및 메일 그룹에 대한 전송 제한 기능 향상(제한된 메일 그룹)”을 참조하십시오.
  • 사용자를 찾고 메일 그룹을 개별 받는 사람으로 확장하는 분류 작업 이후 및 라우팅 과정 중에 메시지를 추적할 수 있습니다. 또한 Exchange System Manager를 사용하여 메시지 추적 로그를 이동할 수 있습니다. 자세한 내용은 Exchange Server 2003 관리 기능에서 “향상된 메시지 추적”을 참조하십시오.
  • 큐 뷰어가 향상되었습니다. 추가로 표시되는 큐를 통해 메일 흐름과 관련된 문제를 더 쉽게 진단할 수 있습니다. 자세한 내용은 Exchange Server 2003 관리 기능에서 “향상된 큐 뷰어”를 참조하십시오.
  • 사서함 저장소에서 사용할 수 있는 보관 기능을 사용하여 숨은 참조란에 있는 대상을 포함한 모든 받는 사람을 보관할 수 있습니다. 자세한 내용은 Exchange Server 2003 관리 기능에서 “보관된 메시지에 숨은 참조 포함”을 참조하십시오.

연결 상태

Exchange에서는 메시징 연결의 현재 상태와 순위를 기준으로 연결 상태 라우팅을 사용하여 서버 간에 메시지를 보내는 가장 좋은 방법을 결정합니다. 새 버전의 Exchange에서는 메시지를 보낼 대체 경로가 없거나 연결이 진동 상태(간헐적으로 사용 가능 여부가 변경되는 상태)일 때 연결 상태 정보가 통신되는 방법이 향상되었습니다. 즉, 연결이 진동 상태이거나 대체 경로가 없으면 Exchange 2003에서는 연결 상태 정보를 생략하여 연결 상태 트래픽을 줄입니다.

향상된 연결 상태 사용 가능성

Exchange 2003에서는 연결 대체 경로가 없는 경우에도 연결 상태가 서비스 중인 것으로 항상 표시됩니다. 다시 말해 Exchange에서는 대체 경로가 없어도 연결 상태를 사용 불가능한 것으로 변경하지 않습니다. 대신 배달할 메일을 잠시 대기시켰다가 경로를 다시 사용할 수 있을 때 보냅니다. 이러한 기능 변경은 연결 상태 정보의 전파를 줄여 성능을 향상시키는 데 도움을 줍니다.

진동 연결에 대한 연결 상태 향상

연결 상태 라우팅과 관련하여 Exchange 2003에서 진동 연결을 처리하는 방법도 향상되었습니다. Exchange 2003에서는 연결 상태 큐를 검토하여 특정 간격 동안 커넥터의 상태가 여러 번 충돌하면 해당 커넥터를 진동 연결로 간주하고 연결 상태를 서비스 중인 것으로 계속 표시합니다. 이런 경우에는 연결 상태를 계속 변경하는 것보다 진동 커넥터를 사용 가능한 상태로 두는 것이 효율적이며 이 방법은 결과적으로 서버 간에 복제되는 연결 상태 정보의 양도 줄이는 데 도움을 줍니다.

상호 포리스트 SMTP 메일 공동 작업 구성

ID 스푸핑 또는 위조를 방지하기 위해 Exchange 2003에서는 인증 과정을 거친 후에만 보낸 사람의 이름이 GAL(전체 주소 목록)의 표시 이름으로 확인됩니다. 따라서 두 포리스트에 걸쳐 있는 조직에서 한 포리스트에서 다른 포리스트로 메일을 보내는 사용자는 인증을 거치지 않습니다. 더구나 사용자가 대상 포리스트의 연락처라 하더라도 사용자의 이름은 GAL의 표시 이름으로 확인되지 않습니다.

Exchange 2003에서 상호 포리스트 메일 공동 작업을 사용하려면 조직 외부의 연락처를 Active Directory에 있는 표시 이름으로 확인하기 위한 추가 구성 단계가 필요합니다. 다음 두 가지 옵션 중 하나를 사용하여 이러한 연락처를 확인할 수 있습니다.

  • 옵션 1(권장) 인증된 사용자만 특정 포리스트에서 다른 포리스트로 메일을 보내고 해당 사용자의 이름이 GAL에 있는 표시 이름으로 확인되도록 인증을 사용합니다.
  • 옵션 2 상호 포리스트 공동 작업에 사용되는 SMTP 가상 서버에 대한 액세스를 제한한 다음 익명 전자 메일을 확인하도록 Exchange를 구성합니다. 이 구성은 사용 가능하지만 권장되지 않습니다. 기본적으로 이 구성을 사용하면 포리스트 간에 메일을 보낼 때 Exch50 메시지 속성(메시지의 확장 속성)이 유지되지 않습니다.

익명 메일 전송 및 상호 포리스트 인증 메일 전송을 보여 주는 다음의 두 가지 시나리오는 상호 포리스트 메일 공동 작업을 구성할 때의 장점을 이해하는 데 도움을 줍니다.

시나리오: 익명 메일 전송

익명 전송인 경우에는 전자 메일 주소가 확인되지 않습니다. 따라서 내부 사용자의 ID를 위장하거나 위조한 익명 사용자가 메일을 보내면 반송 주소는 GAL(전체 주소 목록)에 있는 표시 이름으로 확인되지 않습니다.

예:

Northwind Traders의 정식 내부 사용자인 Kim Akers는 GAL의 표시 이름이 Kim Akers이고 전자 메일 주소는 kim@northwindtraders.com입니다.

메일을 보내려면 Kim은 인증을 거쳐야 합니다. Kim은 이미 인증되어 있으므로 Kim의 메일을 받는 사람에게는 보낸 사람이 Kim Akers로 표시되며 Kim Akers의 속성이 그녀의 GAL 항목으로 표시됩니다. 그러나 Ted Bremer라는 사람이 Kim의 주소로 위장하기 위해 보낸 사람란에 kim@northwindtraders.com을 입력하여 Northwind Traders의 Exchange 2003 서버로 메일을 보내면 Ted는 인증될 수 없으므로 전자 메일 주소는 Kim의 표시 이름으로 확인되지 않습니다. 따라서 Microsoft Office Outlook®에서 이 전자 메일 메시지를 보면 Kim이 보낸 인증된 메일과 달리 보낸 사람 주소가 Kim Akers로 확인되지 않고 kim@northwindtraders.com으로 표시됩니다.

시나리오: 상호 포리스트 메일 배달

Adatum과 Fabrikam이라는 두 개의 포리스트에 걸쳐 있는 회사가 있다고 가정해 봅니다. 두 포리스트 모두 단일 도메인 포리스트이며 도메인 이름이 각각 adatum.com과 fabrikam.com입니다. 상호 포리스트 메일 공동 작업을 위해 Adatum 포리스트의 모든 사용자가 Fabrikam 포리스트의 Active Directory에 연락처로 표시되어 있고 마찬가지로 Fabrikam 포리스트의 모든 사용자도 Adatum 포리스트의 Active Directory에 연락처로 표시되어 있습니다.

Adatum 포리스트의 사용자가 익명 연결을 통해 Fabrikam 포리스트에 메일을 전송하면 메일을 보낸 사용자가 Active Directory와 Outlook GAL에 연락처로 추가되어 있는 경우에도 해당 사용자의 주소가 확인되지 않습니다. 이는 메일을 보낸 Adatum 포리스트 사용자가 Fabrikam 포리스트의 인증된 사용자가 아니기 때문입니다.

예:

Adatum 포리스트의 메일 사용자인 Kim Akers의 전자 메일 주소는 kim@adatum.com이고 Outlook GAL 표시 이름은 Kim Akers입니다. Fabrikam 포리스트의 사용자인 Adam Barr의 전자 메일 주소는 abarr@fabrikam.com이고 Outlook GAL 표시 이름은 Adam Barr입니다. Adam은 Adatum 포리스트의 Active Directory에 연락처로 표시되므로 Kim은 Adam의 전자 메일 주소를 보고 이 주소로 Outlook GAL에서 그의 표시 이름인 Adam Barr를 확인할 수 있습니다. 그러나 Kim이 Adam에게 메일을 보내면 Kim의 주소가 확인되지 않으며 GAL에 있는 Kim의 표시 이름 대신 확인되지 않은 전자 메일 주소인 kim@adatum.com이 표시됩니다. 이 경우 Kim은 익명 사용자로 메일을 보냈기 때문에 그녀의 전자 메일 주소가 확인될 수 없습니다. Kim은 메일을 보낼 때는 인증되어 있지만 두 포리스트 사이의 연결은 인증되어 있지 않습니다.

특정 포리스트의 사용자가 다른 포리스트의 사용자에게 메일을 보내고 메일을 보낸 사람의 전자 메일 주소가 GAL에 있는 해당 사용자의 표시 이름으로 확인되려면 상호 포리스트 메일 공동 작업을 구성해야 합니다. 다음 섹션에서는 두 포리스트 간의 메일 공동 작업을 구성하는 데 사용할 수 있는 두 가지 옵션에 대해 설명합니다.

상호 포리스트 인증 설정

상호 포리스트 SMTP 인증을 사용 가능하게 설정하려면 상대방 포리스트의 인증된 계정을 사용하는 커넥터를 각 포리스트에 만들어야 합니다. 이렇게 하면 두 포리스트 간에 인증된 사용자가 보내는 모든 메일은 GAL에 있는 적절한 표시 이름으로 확인됩니다. 이 섹션에서는 상호 포리스트 인증을 사용 가능하게 설정하는 방법에 대해 설명합니다.

Adatum 포리스트와 Fabrikam 포리스트의 예제(이 항목의 앞부분에서 나오는 “상호 포리스트 메일 배달” 시나리오 참조)를 사용하여 다음 단계에 따라 상호 포리스트 인증을 설정해 보겠습니다.

  1. Fabrikam 포리스트에 다른 사람 이름으로 보내기 권한이 있는 계정을 만듭니다. Adatum 포리스트의 모든 사용자는 Fabrikam 포리스트에도 연락처가 있으므로 Adatum 사용자는 이 계정을 사용하여 인증된 메일을 보낼 수 있습니다. Adatum으로부터 받는 메일을 수락할 모든 Exchange 서버에 이들 사용 권한을 구성합니다.
  2. 아웃바운드 메일을 보낼 때 이 계정으로 인증을 받아야 하는 커넥터를 Adatum 포리스트의 Exchange 서버에 만듭니다.

마찬가지로 Fabrikam 포리스트에서 Adatum 포리스트로의 상호 포리스트 인증을 설정하려면 위의 단계를 반복하여 Adatum에 계정을 만들고 Fabrikam에 커넥터를 만듭니다. 자세한 내용은 Exchange Server 2003 배포 가이드의 "상호 포리스트 SMTP 인증 사용 설정 방법"을 참조하십시오.

익명 메일을 확인하여 상호 포리스트 공동 작업 사용

익명 전자 메일을 확인하도록 Exchange를 구성하는 방법으로 조직 외부의 연락처를 Active Directory의 해당 표시 이름으로 확인하도록 Exchange를 구성할 수도 있습니다. 회사가 Adatum과 Fabrikam이라는 두 개의 포리스트에 걸쳐 있다고 가정해 봅니다.

중요

익명 메일 전송을 확인하도록 Exchange 서버를 구성하면 악의 있는 사용자가 위조된 반송 주소를 사용하여 메시지를 전송할 수 있습니다. 이 경우 받는 사람은 인증된 메일과 위장된 메일을 구분하기 힘듭니다. 이러한 가능성을 줄이려면 Exchange 서버의 IP 주소에서만 SMTP 가상 서버에 액세스할 수 있도록 제한해야 합니다.

Adatum 사용자의 연락처를 Fabrikam 포리스트에서 해당 표시 이름으로 확인하려면 다음 단계를 수행하십시오.

  1. Fabrikam 포리스트에 연결하는 커넥터를 Adatum 포리스트에 만듭니다.
  2. Fabrikam 포리스트의 받는 브리지헤드 서버에서 IP 주소를 기준으로 SMTP 가상 서버에 대한 액세스를 제한합니다. 이렇게 하면 Adatum 포리스트의 서버에서만 이 서버에 메일을 보낼 수 있습니다.
  3. 커넥터를 호스트하는 SMTP 가상 서버에서 익명 전자 메일 확인 설정을 활성화합니다.
  4. 확장 메시지 속성(Exch50 속성)이 포리스트 간에 유지되도록 레지스트리 키를 변경합니다. 레지스트리 키를 변경하지 않으면 중요한 메시지 정보가 손실될 수 있습니다.

위의 단계를 완료하면 Adatum 포리스트에서 Fabrikam 포리스트로 메일을 보내는 모든 사용자는 Fabrikam GAL에 해당 표시 이름으로 확인됩니다. 이 작업을 완료한 후에는 Fabrikam 포리스트에 대해서도 1 - 3단계를 반복해야 합니다.

아래의 절차는 다음과 같은 작업을 수행하는 방법을 설명합니다.

  • Fabrikam에 대한 커넥터를 Adatum 포리스트에 설정
  • Fabrikam 포리스트의 받는 브리지헤드 서버에 대한 액세스 제한
  • Fabrikam 포리스트에서 Adatum 연락처를 확인할 수 있도록 받는 브리지헤드 서버의 SMTP 가상 서버에 익명 전자 메일 확인 기능 설정

생산 환경에서는 Adatum 포리스트에서도 Fabrikam 연락처가 확인될 수 있도록 이 과정을 반복해야 합니다.

1단계: 연결 포리스트에 커넥터 만들기

먼저 연결 포리스트에 커넥터를 만들어야 합니다. 자세한 내용은 연결 포리스트에서 커넥터 생성 방법을 참조하십시오.

상호 포리스트 인증에 사용되는 계정을 만드는 방법에 대한 자세한 내용은 Exchanger Server 2003 전송 및 라우팅 가이드의 "상호 포리스트 인증에 사용되는 계정 생성 방법"을 참조하십시오.

이제 Exchange는 이 커넥터를 통해 fabrikam.com(Fabrikam 포리스트)으로 보낼 모든 메일을 라우팅합니다.

2단계: 받는 브리지헤드 서버에서 IP 주소 제한

연결 포리스트인 Adatum 포리스트에 커넥터를 만든 후에는 받는 브리지헤드 서버에 대한 액세스를 제한해야 합니다. 그러려면 Adatum 포리스트에 있는 연결 서버의 IP 주소만 Fabrikam 포리스트의 받는 브리지헤드 서버에 메일을 보낼 수 있도록 허용해야 합니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "받는 브리지헤드 서버에서 IP 주소별로 액세스 제한 방법"을 참조하십시오.

3단계: SMTP 가상 서버에서 익명 메일 확인

받는 브리지헤드 서버에서 액세스를 제한한 후에는 익명 전자 메일 주소를 확인하도록 해당 브리지헤드 서버의 SMTP 가상 서버를 구성해야 합니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드에서 "익명 전자 메일 주소를 확인하도록 SMTP 가상 서버 구성 방법"을 참조하십시오.

4단계: 포리스트 간에 메시지 속성이 유지되도록 레지스트리 키 설정

앞에서 설명한 대로 포리스트 간에 익명으로 메시지를 보내면 메시지의 확장 메시지 속성은 전송되지 않습니다. 상호 포리스트 시나리오를 구현하는 단일 회사인 경우에는 메시지 속성을 전송하지 않으면 메시지에 대한 정보가 손실될 수 있습니다. 예를 들어 확장 Exchange 속성 중 하나인 SCL 속성에는 타사 솔루션에서 생성된 스팸 메일 등급이 들어 있는데 익명으로 메일을 보내면 이 속성이 전송되지 않습니다. 따라서 Adatum 포리스트에 타사의 스팸 메일 방지 솔루션이 배포되어 있는 경우 이 포리스트에 Fabrikam 포리스트의 받는 사람에게 보낼 메시지가 도착하면 이 타사 솔루션은 메시지에 SCL 속성을 등록합니다. 그러나 메시지를 Fabrikam 포리스트에 배달하면 스팸 메일 등급이 포함된 확장 속성이 유지되지 않습니다.

포리스트 간에 익명으로 메일을 보낼 때 확장 메시지 속성도 함께 전송하려면 받는 브리지헤드 서버에 레지스트리 키를 설정해야 합니다.

확장 메시지 속성을 받도록 Exchange를 구성하려면 받는 브리지헤드 서버 또는 브리지헤드에 있는 SMTP 가상 서버에 레지스트리 키를 설정해야 합니다. Exchange 서버에 레지스트리 키를 사용하도록 설정하면 Exchange 서버의 모든 SMTP 가상 서버가 확장 속성을 허용하도록 구성됩니다.

익명 연결을 통해 보낸 확장 메시지 속성을 수락하도록 Exchange 서버 구성

다음 절차를 사용하면 익명 연결을 통해 전송되는 확장 속성을 수락하도록 Exchange 서버를 구성할 수 있습니다. Exchange 서버를 상호 포리스트 통신용 브리지헤드 서버로만 사용하는 경우에는 서버 수준에서 이 설정을 구성하는 것이 좋습니다. 이 Exchange 서버에 다른 SMTP 가상 서버가 있는 경우에는 SMTP 가상 서버에만 이 레지스트리 키를 설정하는 것이 좋습니다.

참고

Exchange 서버에 이 레지스트리 키를 사용하도록 설정하면 해당 Exchange 서버의 모든 SMTP 가상 서버에 설정이 적용됩니다. 단일 SMTP 가상 서버에만 이 설정을 적용하려면 해당 SMTP 가상 서버에 레지스트리 키를 설정하십시오.

경고

레지스트리를 잘못 편집하면 운영 체제를 다시 설치해야 하는 심각한 문제가 발생할 수 있습니다. 이 문제를 해결하지 못할 수도 있습니다. 레지스트리를 편집하려면 먼저 중요 데이터를 백업하십시오.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "익명으로 보낸 메시지 확장 속성을 수락하도록 Exchange 서버 사용 설정 방법"을 참조하십시오.

익명으로 보낸 확장 메시지 속성을 수락하도록 SMTP 가상 서버 구성

다음 절차를 사용하면 확장 속성을 수락하도록 Exchange 서버의 SMTP 가상 서버를 구성할 수 있습니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "익명으로 보낸 메시지 확장 속성을 수락하도록 Exchange 서버 사용 설정 방법"을 참조하십시오.

인터넷 메일 마법사

Exchange Server 버전 5.5에서 관리자는 인터넷 메일 마법사를 사용하여 인터넷 메일을 설정할 수 있습니다. Exchange 2003에서 제공하는 인터넷 메일 마법사 버전을 사용하면 Exchange 2000 Server 또는 Exchange Server 2003과의 인터넷 메일 연결을 쉽게 구성할 수 있습니다. 인터넷 메일 마법사는 대기업보다는 환경이 덜 복잡한 중소기업에서 사용되도록 고안되었습니다.

이 마법사는 인터넷 메일을 보내고 받도록 Exchange 서버를 구성하는 과정을 단계적으로 안내합니다. 마법사는 먼저 보내는 인터넷 메일에 필요한 SMTP 커넥터를 만들고 받는 메일을 수락하도록 SMTP 가상 서버를 구성합니다. Exchange 서버에 이미 SMTP 커넥터를 설정했거나 추가 SMTP 가상 서버를 만든 경우에는 서버 구성을 기본 상태로 되돌려야만 인터넷 메일 마법사를 실행할 수 있습니다.

참고

인터넷 메일 마법사는 Exchange 2000 Server 이상 버전에 대해서만 인터넷 메일을 구성할 수 있습니다. 이전 버전의 Exchange를 실행하는 경우에도 서버를 사용하여 인터넷에서 메일을 보내거나 받을 수 있지만 인터넷 메일 마법사를 사용하여 인터넷 메일을 구성할 수는 없습니다.

인터넷 메일 마법사를 실행하면 구성을 성공적으로 변경했는지를 비롯하여 모든 구성 변경 사항이 들어 있는 로그 파일(Exchange Internet Mail Wizard.log)이 만들어집니다. 이 로그 파일은 마법사를 실행한 사용자의 My Documents 폴더에 저장됩니다.

이후의 섹션에서는 인터넷 메일 마법사를 사용하여 다음과 같은 작업을 수행하는 방법에 대해 설명합니다.

  • 인터넷 메일을 보내도록 Exchange 서버 구성
  • 인터넷 메일을 받도록 Exchange 서버 구성
  • 인터넷 메일을 주고받도록 Exchange 서버 구성
  • 인터넷 메일용으로 사용할 이중 홈 Exchange 서버 구성

인터넷 메일을 보내도록 Exchange 서버 구성

인터넷 메일을 보내도록 Exchange 서버를 구성하면 인터넷 메일 마법사는 선택한 서버를 아웃바운드 브리지헤드 서버로 구성하고 사용자가 지정한 인터넷 주소로 메일을 보내는 데 사용할 커넥터를 해당 서버에 만듭니다.

자세한 내용은 인터넷 메일 마법사를 실행하고 인터넷 메일을 보내도록 서버를 구성하는 방법을 참조하십시오.

인터넷 메일을 받도록 Exchange 서버 구성

인터넷 메일 마법사를 실행하면 Exchange 서버는 지정한 SMTP 도메인의 모든 인터넷 메일을 수락합니다.

자세한 내용은 인터넷 메일 마법사를 실행하고 인터넷 메일을 받도록 서버를 구성하는 방법을 참조하십시오.

인터넷 메일을 주고받도록 Exchange 서버 구성

인터넷 메일 마법사를 실행하면 Exchange 서버는 지정한 구성에 따라 모든 인터넷 메일을 주고받습니다.

자세한 내용은 인터넷 메일 마법사를 실행하고 인터넷 메일을 주고받도록 서버를 구성하는 방법을 참조하십시오.

인터넷 메일용으로 사용할 이중 홈 Exchange Server 구성

인터넷 메일 마법사를 실행하면 Exchange 서버는 지정한 구성에 따라 모든 인터넷 메일을 주고받습니다.

자세한 내용은 이중 홈 서버에서 인터넷 메일 마법사 실행 방법을 참조하십시오.

DSN 진단 로깅 및 DSN 코드

Exchange 2003에서는 배달 상태 알림(DSN)이 다음과 같이 향상되었습니다.

  • 새로운 DSN 로깅 범주가 추가되었습니다.
  • 메시지 흐름 문제를 해결하는 데 도움을 주는 새 DSN 코드가 추가되었습니다.

DSN 진단 로깅 구성

배달 못 함 보고서(NDR)라고도 하는 DSN에 대한 진단 로깅을 구성할 수 있습니다.

자세한 내용은 DSN에 대해 진단 로깅 구성 방법을 참조하십시오.

Exchange Server 2003에 제공되는 DSN 코드

다음 표는 Exchange 2003에서 전송 및 라우팅과 관련하여 제공하는 DSN 메시지를 보여 줍니다.

Exchange 2003에서는 새로운 배달 상태 알림 기능을 사용할 수 있습니다.

DSN 코드 원인 해결 방법

4.2.2

Exchange 2000에서는 받는 사람의 사서함이 할당량 제한을 초과했을 때 이 배달 상태 알림이 생성됩니다.

Windows® 2000 및 Microsoft Windows Server™ 2003의 경우에는 Drop 디렉터리(배달할 메시지를 저장할 수 있는 디렉터리)의 저장 공간 크기가 SMTP 가상 서버 디스크 할당량을 초과했을 때 이 메시지가 생성됩니다. SMTP 가상 서버의 디스크 할당량은 가상 서버의 최대 메시지 크기의 11배이며 최대 메시지 크기가 지정되지 않은 경우 기본값은 22MB입니다. 디스크 공간이 할당량의 최대 메시지 크기 또는 2MB(최대 메시지의 크기가 지정되지 않은 경우)를 넘지 않으면 Exchange는 받는 메시지가 디스크 할당량를 초과할 것으로 간주하고 DSN을 생성합니다.

사서함 저장소 및 큐 저장소 할당량 제한을 확인하십시오.

4.4.9

일시적인 라우팅 오류가 발생했거나 라우팅 구성이 잘못되었음을 나타냅니다. 가능한 원인은 다음과 같습니다.

  • 사용자가 스마트 호스트 대신 DNS를 사용하도록 SMTP 커넥터를 구성한 후 이 커넥터에 비SMTP 주소 공간(예: X.400 주소)을 추가했습니다.
  • 다른 사용자가 만든 라우팅 그룹의 받는 사람에게 메일을 보냈습니다. 이때 DNS를 사용하는 라우팅 그룹 커넥터를 사용하여 라우팅 그룹을 연결하다가 이 관리 그룹 또는 라우팅 그룹이 제거되었습니다. 따라서 이 라우팅 그룹에 보낸 모든 메일은 MSGWIA.X500 형식(비SMTP 주소에 대해 사용되는 주소 캡슐화)으로 보내지므로 DNS에서 형식을 인식할 수 없습니다.

라우팅에서 이러한 경우를 감지하면 Exchange는 DSN을 반환합니다.

  • 첫 번째 시나리오의 문제를 해결하려면 DNS 대신 스마트 호스트를 사용하도록 SMTP 커넥터를 구성하여 비SMTP 주소 공간 문제를 해결하십시오.
  • 두 번째 시나리오의 문제를 해결하려면 제거된 관리 그룹 또는 라우팅 그룹의 모든 사용자를 유효한 그룹으로 이동했는지 확인하십시오.

5.3.0

Exchange 2003은 메시지 전송 에이전트(MTA) 없이도 작동합니다. 실수로 메일을 MTA로 보내면 Exchange는 메일을 보낸 사람에게 이 DSN을 반환합니다. 이는 MTA 서비스를 비활성화하고 특정 레지스트리 설정을 사용하여 MTA/저장소 드라이버를 비활성화한 경우에만 적용됩니다. 기본 구성을 사용하면 잘못 라우팅된 메일은 MTA 큐에 저장됩니다.

라우팅 토폴로지를 확인하고 Winroute 도구를 사용하여 서버와 라우팅 그룹 간에 경로가 제대로 복제되었는지 확인하십시오.

5.7.1

메시지를 보낸 사람이 배달을 완료하는 데 필요한 충분한 권한이 없어 일반적인 액세스 및 보낸 사람 액세스가 거부되었습니다.

가능한 원인은 다음과 같습니다.

  • 메시지를 보낸 사람이 배달을 완료하는 데 필요한 충분한 권한이 없습니다.
  • 릴레이가 허용되지 않은 다른 Exchange 2000 서버를 통해 메일을 릴레이하려고 시도했습니다. 이 경우 원격 서버에서 5.7.1 코드를 반환합니다.
  • 받는 사람의 사서함에 배달 제한이 설정되어 있습니다. 예를 들어 메일 그룹에서 보낸 메일만 받도록 받는 사람의 사서함 배달이 제한되어 있으면 구성원 이외의 사람이 보낸 메일은 거부되고 DSN 코드가 반환됩니다.
  • Exchange 2003의 새로운 기능: 익명의 사용자가 인증된 SMTP 세션의 메일만 수락하는 받는 사람 또는 메일 그룹으로 메일을 보내려고 했습니다.

연락처에 대한 시스템 권한과 특성을 확인한 다음 메시지를 다시 보내십시오. 또한 알려진 다른 문제가 발생하지 않도록 Exchange 2000 서비스 팩 1이상을 실행하십시오. Exchange 2003의 경우 대상 메일 그룹이 제한된 메일 그룹이 아닌지 해당 메일 그룹의 사용 권한을 확인하십시오.

X.400(MTA) 및 SMTP 큐 디렉터리 위치 이동

Exchange 2003을 사용하면 SMTP 가상 서버 및 X.400 프로토콜의 큐 디렉터리 위치를 변경할 수 있습니다.

자세한 내용은 X.400(MTA) 큐 데이터 이동 방법SMTP 큐 데이터 이동 방법을 참조하십시오.

연결 필터링

Exchange Server 2003에서는 차단 목록을 기반으로 하는 연결 필터링 기능을 사용할 수 있습니다. 연결 필터링은 IP 주소를 기준으로 원치 않는 전자 메일의 알려진 출처, 전화 접속 사용자 계정, 오픈 릴레이용 서버 등이 모두 나열된 외부 서비스를 활용합니다. 연결 필터링은 타사 콘텐츠 필터 제품을 보완하는 데 사용됩니다. 이 기능을 사용하면 들어오는 IP 주소가 공급자의 차단 목록에서 필터링하려는 범주에 속하는지 확인할 수 있습니다. 차단 목록 공급자의 목록에 일치하는 IP 주소가 있으면 SMTP에서 RCPT TO 명령에 대한 응답으로 “550 5.x.x" 오류를 반환하고 사용자 지정된 오류 응답을 보낸 사람에게 보냅니다. RCPT TO 명령은 연결 서버에서 메시지의 받는 사람을 식별하는 데 사용하는 SMTP 명령입니다. 또한 여러 연결 필터를 사용하고 각 필터가 적용되는 우선 순위를 지정할 수도 있습니다.

연결 필터링을 사용하면 다음을 수행할 수 있습니다.

  • 차단 목록 서비스 공급자를 사용하여 다음과 같은 사항을 확인하는 연결 필터링 규칙을 설정할 수 있습니다.
    • 원치 않는 상업 전자 메일을 보내는 사람의 IP 주소
    • 오픈 릴레이용으로 구성된 서버
    • 전화 접속 사용자 계정 목록
  • 전체 수락 및 거부 목록을 구성할 수 있습니다. 전체 수락 목록은 메일을 항상 수락할 IP 주소 목록이고 전체 거부 목록은 메일을 항상 거부할 IP 주소 목록입니다. 차단 목록 서비스 공급자가 없어도 전체 수락 및 거부 목록을 사용할 수 있습니다.
  • 모든 연결 필터 규칙의 영향을 받지 않는 받는 사람 주소를 구성할 수 있습니다. 모든 연결 필터의 영향을 받지 않은 예외적인 받는 사람 주소를 구성할 수 있습니다. 이 주소로 메일을 보내면 보낸 사람이 차단 목록에 들어 있는 경우에도 메일이 자동으로 수락됩니다.

연결 필터링 규칙 작동 방법

연결 필터링 규칙을 만들면 SMTP는 이 규칙을 사용하여 타사 차단 목록 서비스에서 제공한 목록에서 DNS 조회를 수행합니다. 이 과정에서 연결 필터는 들어오는 각 IP 주소를 타사 차단 목록과 비교하며 차단 목록 공급자는 다음 두 가지 응답 중 하나를 생성합니다.

  • 호스트를 찾을 수 없습니다. IP 주소가 차단 목록에 없음을 나타냅니다.
  • 127.0.0.x IP 주소와 일치하는 주소가 차단 대상 목록에 있음을 나타내는 응답 상태 코드입니다. x는 차단 목록 공급자에 따라 달라집니다.

들어오는 IP 주소가 차단 목록에 있으면 SMTP는 RCPT TO 명령(연결 서버에서 메시지 받는 사람을 식별하기 위해 실행하는 SMTP 명령)에 대한 응답으로 5.x.x 오류를 반환합니다.

보낸 사람에게 반환되는 응답을 사용자 지정할 수 있습니다. 일반적으로 차단 목록 공급자마다 차단 대상 범주가 다르기 때문에 사용자는 거부하고자 하는 일치 항목을 직접 지정할 수 있습니다. 대부분의 차단 목록 공급자는 다음과 같은 세 가지 유형의 차단 대상을 선별합니다.

  • 원치 않는 상업성 전자 메일의 출처. 이 목록은 원치 않는 상업성 전자 메일을 검색하여 해당 원본 주소를 추가하는 방법으로 만들어집니다.
  • 알려진 오픈 릴레이 서버. 이러한 목록은 인터넷상의 오픈 릴레이 SMTP 서버를 식별하는 방법으로 만들어집니다. 오픈 릴레이 서버가 생기는 가장 흔한 이유는 시스템 관리자가 서버를 잘못 구성한 경우입니다.
  • 전화 접속 사용자 목록. 이러한 목록은 전화 접속 액세스를 사용하는 IP 주소가 포함된 기존 인터넷 서비스 공급자(ISP) 목록을 기준으로 만들어지거나 전화 접속 연결을 사용하는 것으로 의심되는 주소를 검색하는 방법으로 만들어집니다.

차단 목록 공급자가 일치하는 공격 IP 주소를 찾는 방법

연결 필터를 설정한 후 전자 메일 메시지를 조직에 보내면 Exchange에서 차단 목록 공급자에게 연결합니다. 공급자는 DNS에서 A(호스트) 레코드가 있는지 확인합니다. Exchange에서는 이 정보를 특정 형식으로 쿼리합니다. 예를 들어 연결 주소가 192.168.5.1이고 차단 목록 공급자의 조직이 contoso.org인 경우 다음 레코드가 있는지 쿼리합니다.

<reverse IP address of the connecting server>.<dns name for the block list organization> IN A 127. 0.0.x

이 경우에는 다음과 같습니다.

1.5.168.192..contoso.org

이 IP 주소가 공급자 목록에 있으면 공급자는 공격 IP 주소 및 공격 유형을 나타내는 127.0.0.x 상태 코드를 반환합니다. 모든 차단 목록 공급자는 응답 코드 127.0.0.x를 반환합니다. 여기서 x는 공격 유형을 나타냅니다. 이 숫자는 차단 목록 공급자에 따라 다릅니다.

차단 목록 공급자 응답 코드에 대한 이해

앞에서 설명한 것처럼 차단 목록 공급자가 일치하는 항목을 찾으면 항상 상태 코드 127.0.0.x를 반환합니다. 상태 코드는 명시적 반환 코드이거나 다기능 반환 코드인 비트 마스크입니다. 차단 목록 공급자가 값을 반환하면 필터링할 값을 지정할 수 있습니다. 그러나 차단 목록 공급자가 비트 마스크를 반환하는 경우에는 비트 마스크가 필터링할 일치 항목을 지정하기 위해 어떻게 작동하는지 이해해야 합니다.

비트 마스크는 항목에 특정 비트가 설정되어 있는지 확인하는 데 사용합니다. 비트 마스크는 특정 비트 값을 확인한다는 점에서 일반적인 마스크와 구별되며 값 범위를 확인하는 서브넷 마스크와 대조됩니다. 다음 예제를 살펴 보겠습니다.

차단 목록의 각 일치 항목에 대해 차단 목록 공급자가 다음 표에 나열된 상태 코드를 반환한다고 가정합니다.

차단 목록 상태 코드 예제

범주 반환된 상태 코드

원치 않는 전자 메일의 알려진 출처

127.0.0.3

전화 접속 사용자 계정

127.0.0.2

알려진 릴레이 서버

127.0.0.4

그러나 IP 주소가 두 목록에 모두 들어 있으면 차단 목록 공급자는 끝에 있는 8진수 값을 더합니다. 따라서 IP 주소가 알려진 릴레이 서버 목록 및 원치 않는 전자 메일 출처 목록에 있으면 차단 목록 공급자는 상태 코드 127.0.7을 반환합니다. 7은 원치 않는 상업성 전자 메일의 알려진 출처 및 알려진 릴레이 서버에 대해 반환된 코드 끝에 있는 8진수 값을 더한 값입니다.

원치 않는 상업성 전자 메일의 알려진 출처에 대해서만 필터링하려면 비트 마스크 값 0.0.0.3을 입력합니다. 그러면 차단 목록에서 가능한 모든 값을 필터링합니다. 이 예제에서는 127.0.0.3, 127.0.0.5, 127.0.0.7 및 127.0.0.9를 필터링합니다.

다음 표는 각 예제 상태 코드와 관련된 비트 마스크 값을 보여 줍니다.

차단 목록 상태 코드와 해당 비트 마스크 예제

범주 반환된 상태 코드 비트 마스크

원치 않는 전자 메일의 알려진 출처

127.0.0.3

0.0.0.3

전화 접속 사용자 계정

127.0.0.2

0.0.0.2

알려진 릴레이 서버

127.0.0.4

0.0.0.4

알려진 릴레이 서버 및 전화 접속 사용자 계정

127.0.0.6

0.0.0.6

알려진 릴레이 서버 및 전화 접속 사용자 계정 범주의 경우 비트 마스크 0.0.0.6은 IP 주소가 알려진 릴레이 서버 및 전화 접속 사용자 계정 목록 모두에 나타날 경우에만 IP 주소의 일치 항목을 반환합니다. IP 주소가 두 목록 중 하나에만 나타날 경우에는 일치 항목을 반환하지 않습니다. 여러 목록에서 단일 일치 항목을 확인할 때는 비트 마스크를 사용할 수 없습니다.

참고

비트 마스크는 단일 값만 검사합니다. IP 주소가 두 개의 목록에 포함될 경우 반환되는 비트 마스크 값을 설정하면 두 가지 목록에 모두 포함되는 IP 주소만 일치합니다. 두 목록 중 하나에서 IP 주소를 확인하려면 이 설정의 상태 코드를 입력합니다.

연결 필터 규칙에 대한 예외 지정

차단 목록에 포함되었는지에 대한 여부와 상관없이 특정 받는 사람에 대해 메시지 배달을 허용할 수 있습니다. 이 기능은 합법적인 조직이 전자 메일 관리자 계정에 연결하여 관리자와 통신할 수 있게 하려는 경우 유용합니다. 예를 들어 합법적인 회사에 부주의로 오픈 릴레이를 허용하도록 구성된 서버가 있을 경우 이 회사에서 Exchange 서버 사용자에게 보낸 전자 메일 메시지는 차단됩니다. 그러나 조직의 전자 메일 관리자 계정에 메시지를 배달할 수 있도록 연결 필터링을 구성한 경우에는 차단된 회사의 관리자가 전자 메일 관리자 계정에 전자 메일을 보내 해당 상황을 설명하거나 전자 메일이 거부된 이유에 대해 문의할 수 있습니다.

연결 필터링 사용

연결 필터링을 사용하려면 다음 단계를 수행합니다.

  1. 메시지 배달 속성 대화 상자의 연결 필터링 탭을 사용하여 연결 필터를 만듭니다.
  2. SMTP 가상 서버 수준에서 필터를 적용합니다.
  3. SP2의 새로운 기능: 연결 필터링에서 제외할 내부 네트워크 서버를 지정할 수 있습니다.

위의 각 단계는 다음 섹션에 자세히 설명되어 있습니다.

1단계: 연결 필터링 구성

연결 필터링을 구성하려면 다음 작업을 수행합니다.

  • 전체 수락 및 거부 목록 만들기
  • 연결 필터 규칙 만들기
  • 연결 필터 규칙에 대한 예외를 만듭니다.

전체 수락 및 거부 목록 만들기

연결 필터링을 사용하면 전체 수락 및 거부 목록을 만들 수 있습니다. 이러한 목록을 사용하면 차단 목록 서비스 공급자 사용 여부에 상관없이 특정 IP 주소에서 보낸 메일을 항상 수락하거나 항상 거부할 수 있습니다. 전체 수락 목록에 나타나는 모든 IP 주소는 자동으로 수락되며 모든 연결 필터 규칙이 무시됩니다. 마찬가지로 전체 거부 목록에 나타나는 IP 주소는 자동으로 거부됩니다.

전체 수락 목록의 항목은 전체 거부 목록의 항목보다 우선합니다. Exchange에서는 전체 거부 목록을 확인하기 전에 전체 수락 목록을 확인합니다. 따라서 특정 서브넷 및 마스크의 연결을 거부하고 이 범위 내에 있는 단일 IP 주소의 연결을 수락할 경우 다음을 수행하십시오.

  • 전체 수락 목록에 연결을 수락하려는 IP 주소를 입력합니다.
  • 전체 거부 목록에 연결을 거부하려는 IP 주소 범위의 서브넷 및 마스크를 입력합니다.

전체 수락 목록에 추가한 연결 IP 주소에서 Exchange 서버 연결을 시도하면 Exchange에서는 전체 수락 목록을 먼저 확인합니다. Exchange에서 이 IP 주소의 일치 항목을 찾기 때문에 연결이 수락되면 Exchange에서 추가 연결 필터링 확인은 수행되지 않습니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "전체 수락 목록 생성 방법" 및 "전체 거부 목록 생성 방법"을 참조하십시오.

연결 필터 규칙 만들기

연결 필터 규칙을 만드는 방법에 대한 자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "연결 필터 생성 방법"을 참조하십시오.

연결 필터 규칙에 대한 예외를 만들 수 있습니다. 특히 해당 연결 IP 주소가 차단 목록에 있는지 여부와 상관없이 특정한 받는 사람(예: 전자 메일 관리자)에 대해 메시지 배달을 허용할 수 있습니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "연결 규칙에 대한 예외 지정 방법"을 참조하십시오.

2단계: 해당 SMTP 가상 서버에 연결 필터 적용

연결 필터를 만든 후 해당 SMTP 가상 서버에 적용해야 합니다. 일반적으로 인바운드 인터넷 전자 메일을 수락하는 게이트웨이 서버 상의 SMTP 가상 서버에 연결 필터를 적용합니다. 다음 절차를 사용하여 SMTP 가상 서버에 연결 필터를 적용합니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "SMTP 가상 서버에 연결 필터 적용 방법"을 참조하십시오.

SP2의 새로운 기능: 3단계: 연결 필터링에서 제외할 서버 지정

Exchange Server 2003 SP2에서는 네트워크 주변을 벗어난 위치에서 연결 필터링을 사용할 수 있습니다. 이렇게 하려면 메시지 배달 속성 대화 상자의 일반 탭에서 IP 주소 유효성 검사에서 제외할 내부 네트워크 서버의 IP 주소를 지정합니다.

개별 IP 주소를 지정하거나 IP 주소 그룹을 지정할 수 있습니다. 들어오는 SMTP 메일을 처리하는 조직의 서버를 모두 포함해야 합니다. 또한 보낸 사람 ID 및 연결 필터링 배포 서버로 메일을 라우팅하는 서버도 모두 포함시켜야 합니다. SMTP 메일을 처리하는 서버 중 하나가 주변에 있으면 이러한 서버의 모든 주변 IP 주소를 포함해야 합니다.

보낸 사람 ID 또는 연결 필터링 배포 서버에서 받은 전자 메일 메시지의 IP 주소가 이 목록에 있으면 Exchange Server는 보낸 사람 ID 및 연결 필터링 유효성 검사를 실행하지 않고 해당 IP 주소를 건너뜁니다. 목록에 IP 주소를 196개까지 추가할 수 있습니다.

내부 네트워크 서버를 지정하는 방법에 대한 자세한 내용은 Exchange Server 2003 SP2 온라인 도움말에서 "연결 필터링에 대한 IP 주소 구성 데이터 지정"을 참조하십시오.

인바운드 받는 사람 필터링

받는 사람 필터링을 사용하면 모든 잘못된 받는 사람에게 보내는 메일을 차단할 수 있습니다. 또한 받는 사람이 유효한지 또는 유효하지 않은지 여부에 상관없이 받는 사람 필터 목록에 지정된 모든 받는 사람에게 보내는 메일을 차단할 수도 있습니다.

받는 사람 필터를 사용하면 Active Directory 조회를 기준으로 각 받는 사람의 인바운드 메일을 필터링하여 잘못된 받는 사람에게 보내는 메일을 차단합니다. 다음 조건을 기준으로 메일을 필터링할 수 있습니다.

  • Active Directory에 받는 사람이 없는 경우
  • 보낸 사람에게 해당 권한이 없는 경우

이러한 조건에 해당하는 받는 메일은 모두 거부되고 SMTP 세션 동안 SMTP 가상 서버에서 550 5.x.x 오류를 반환합니다.

참고

Exchange에서는 Active Directory 조회만 수행하며 신뢰할 수 있는 도메인으로 보내는 받는 메일의 잘못된 받는 사람을 차단합니다. 이 설정은 받는 사람 정책에 구성되어 있습니다.

올바른 메일 주소 또는 잘못된 메일 주소 여부에 상관없이 조직 내에서 지정된 전자 메일 주소로 보낸 메시지를 필터링하도록 받는 사람 필터링을 구성할 수도 있습니다. 지정된 받는 사람에게 메시지를 보내면 Exchange는 SMTP 세션 동안 5.x.x 수준 오류를 반환합니다.

기본적으로 Exchange는 올바른 받는 사람 또는 잘못된 받는 사람 여부에 상관없이 모든 받는 사람에게 전달된 메일을 수락한 다음 모든 잘못된 받는 사람에 대해 배달 못 함 보고서(NDR)를 보냅니다. 또한 원하지 않는 메일은 일반적으로 잘못된 주소에서 보내므로 Exchange는 존재하지 않는 보낸 사람에게 NDR을 다시 배달하여 더 많은 리소스를 소비하게 됩니다. 받는 사람 필터링을 사용하면 잘못된 받는 사람을 필터링하므로 리소스를 더 이상 낭비하지 않아도 됩니다. 그러나 Active Directory에서 받는 사람을 확인하기 위해 받는 사람 필터링을 사용하면 SMTP 세션이 유효한 받는 사람 및 잘못된 받는 사람에 대해 각각 다른 응답을 보내므로 악의적인 목적을 가진 보낸 사람이 유효한 전자 메일 주소를 알아낼 수도 있습니다.

참고

받는 사람 필터 규칙은 익명 연결에만 적용됩니다. 인증된 사용자 및 Exchange 서버는 이러한 유효성 검사를 건너뜁니다.

받는 사람 필터링 사용

받는 사람 필터링을 사용하려면 다음 단계를 수행합니다.

  1. 메시지 배달 속성 대화 상자의 받는 사람 필터링 탭을 사용하여 받는 사람 필터를 만듭니다.
  2. SMTP 가상 서버 수준에서 필터를 적용합니다.

위의 각 단계는 다음 섹션에 자세히 설명되어 있습니다.

1단계: 받는 사람 필터 만들기

먼저 받는 사람 필터를 만들어야 합니다. 자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "받는 사람 필터 생성 방법"을 참조하십시오.

2단계: 해당 SMTP 가상 서버에 받는 사람 필터 적용

받는 사람 필터를 만든 후 해당 SMTP 가상 서버에 적용해야 합니다. 일반적으로 받는 사람 필터는 인바운드 인터넷 전자 메일을 수락하는 게이트웨이 서버에 있는 SMTP 가상 서버에서 적용합니다. 다음 절차를 사용하여 SMTP 가상 서버에 받는 사람 필터를 적용합니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "SMTP 가상 서버에 받는 사람 필터 적용 방법"을 참조하십시오.

SP2의 새로운 기능: 보낸 사람 ID 필터링

Exchange Server 2003 SP2에서는 보낸 사람 ID 필터링을 사용할 수 있습니다. 보낸 사람 ID는 보다 확실히 UCE(원치 않는 상업성 전자 메일)와 피싱 사기를 방지하는 데 사용할 수 있는 전자 메일 업계의 표준 기능입니다. 특히 보낸 사람 ID 프레임워크는 전자 메일 메시지의 보낸 사람을 확인하여 피싱 사기를 방지하고 전자 메일 도메인 스푸핑을 줄이기 위해 만들어진 프로토콜입니다. 보낸 사람 ID에 대한 자세한 내용은 Sender ID 웹 사이트를 참조하십시오.

보낸 사람 ID 구성

다음 개요에서는 Exchange Server 2003 SP2에서 보낸 사람 ID 필터링을 구성하기 위해 따라야 하는 3단계에 대해 설명합니다.

  1. 메시지 배달 속성 대화 상자의 보낸 사람 ID 필터링 탭에서 다음 옵션 중 하나를 선택하여 서버에서 보낸 사람 ID 유효성 검사에 실패한 메시지를 처리하는 방법을 지정합니다.
    • 보낸 사람 ID 필터가 메시지로 확인 결과를 스탬프 처리하고 지능형 메시지 필터와 같은 스팸 방지 처리로 처리하도록 하려면 **수락(스팸 방지 처리를 위해 보낸 사람 ID 상태가 메시지에 첨부됨)**을 선택합니다. 이것이 기본 옵션입니다.
    • 보낸 사람 ID 필터가 메일을 받아들인 다음 사용자에 NDR(배달 못 함 보고서)을 보내지 않고 메일을 삭제하도록 하려면 **삭제(메시지 수락 후 삭제됨. NDR을 보낸 사람에게 다시 보내지 않음)**를 선택합니다.
    • 보낸 사람 ID 필터가 SMTP 프로토콜 수준에서 메일을 거부하고 사용자에게 NDR 메시지를 발행하게 하려면 **거부(메시지 수락 안 함. 보내는 사람이 NDR 생성을 담당함)**를 선택합니다. 특히 보내는 서버에서 NDR 생성을 담당합니다.
  2. IP 주소 유효성 검사에서 제외할 내부 네트워크 서버의 IP 주소를 메시지 배달 속성 대화 상자의 일반 탭에서 지정합니다. 개별 IP 주소를 지정하거나 IP 주소 그룹을 지정할 수 있습니다. Exchange 조직에서 들어오는 SMTP 메일을 처리하는 서버는 모두 포함해야 합니다. 또한 보낸 사람 ID 및 연결 필터링 배포 서버로 메일을 라우팅하는 서버도 모두 포함시켜야 합니다. SMTP 메일을 처리하는 서버 중 하나가 주변에 있으면 이러한 서버의 모든 주변 IP 주소를 포함해야 합니다. 보낸 사람 ID 또는 연결 필터링 배포 서버에서 받은 전자 메일 메시지의 IP 주소가 이 목록에 있으면 Exchange Server는 보낸 사람 ID 및 연결 필터링 유효성 검사를 실행하지 않고 해당 IP 주소를 건너뜁니다. 목록에 IP 주소를 196개까지 추가할 수 있습니다.
  3. SMTP 가상 서버에서 보낸 사람 ID를 사용합니다. 보낸 사람 ID 필터링 옵션을 구성한 후에 Exchange 조직의 SMTP 가상 서버에서 보낸 사람 ID 필터링을 사용하도록 설정해야 합니다.
    각 작업을 수행하는 방법에 대한 자세한 내용은 Exchange Server 2003 SP2 온라인 도움말에서 "보낸 사람 ID 필터링 구성"을 참조하십시오.

SP2의 새로운 기능: 지능형 메시지 필터링

Exchange Server 2003 SP2를 설치할 때 지능형 메시지 필터링도 설치되므로 바로 사용할 수 있습니다.

참고

Exchange Server 2003 설치 프로그램이 지능형 메시지 필터가 실행 중임을 감지했을 경우에는 Exchange Server 2003 SP2 설치로 진행하기 전에 지능형 메시지 필터를 제거할 것인지를 묻는 메시지가 나타납니다.

지능형 메시지 필터링을 사용하면 게이트웨이 SMTP 가상 서버에서 스팸이라고도 하는 UCE(원치 않는 상업성 전자 메일)를 차단할 수 있습니다. 게이트웨이 SMTP 가상 서버는 들어오는 인터넷 전자 메일을 받아들이는 SMTP 가상 서버입니다.

지능형 메시지 필터링에 대한 자세한 내용은 Exchange Intelligent Message Filter 웹 사이트를 참조하십시오.

지능형 메시지 필터링 구성

다음 개요에서는 Exchange Server 2003 SP2에서 보낸 사람 ID 필터링을 구성하기 위해 따라야 하는 단계에 대해 설명합니다.

  1. 메시지 배달 속성 대화 상자의 지능형 메시지 필터링 탭에서 옵션을 사용하여 지능형 메시지 필터를 만듭니다. 지능형 메시지 필터가 다양한 SCL 등급의 전자 메일 메시지를 처리하는 방법을 결정하는 두 개의 임계값을 설정할 수 있습니다. 즉, 하나는 지정된 임계값 이상의 메시지에 대해 관련 작업을 수행하는 게이트웨이 임계값이고 다른 하나는 사서함 저장소 임계값입니다.
    • 메시지의 SCL 등급이 게이트웨이 임계값보다 높으면 지능형 메시지 필터가 지정된 작업을 수행합니다. 이 옵션에는 보관, 삭제, 작업 없음거부가 있습니다.
    • 메시지의 SCL 등급이 게이트웨이 임계값보다 낮으면 해당 메시지는 받는 사람의 Exchange 사서함 저장소로 보내집니다. Exchange 사서함 저장소에서 메시지의 SCL 등급이 사서함 저장소 임계값보다 높으면 사서함 저장소는 메시지를 받은 편지함 대신 사용자의 정크 메일 폴더로 배달합니다.
  2. SMTP 가상 서버에서 지능형 메시지 필터를 사용합니다. 지능형 메시지 필터 옵션을 구성한 후에 Exchange 조직의 SMTP 가상 서버에서 지능형 메시지 필터를 사용하도록 설정해야 합니다.

각 작업을 수행하는 방법에 대한 자세한 내용은 Exchange Server 2003 SP2 온라인 도움말에서 "지능형 메시지 필터링 구성"을 참조하십시오.

SP2의 업데이트된 기능: 사용 가능한 필터를 적용하는 방법 이해

Exchange Server 2003에서는 다음 필터를 지원합니다.

  • 가상 서버 기반의 IP 제한
  • 연결 필터링
  • 받는 사람 필터링
  • 보낸 사람 필터링
  • 보낸 사람 ID 필터링
  • 지능형 메시지 필터링

연결 필터링, 받는 사람 필터링, 보낸 사람 필터링, 보낸 사람 ID 필터링 및 지능형 메시지 필터링은 모두 메시지 배달 속성에서 구성되지만 각 SMTP 가상 서버에서 이 속성을 사용하도록 설정해야 합니다. 이와 달리 IP 제한은 각 SMTP 가상 서버에서 직접 구성됩니다.

이 섹션에서는 이러한 필터가 구성 및 설정될 때 SMTP 세션 동안 확인되는 순서를 보여 줍니다. 필터링 및 IP 제한은 다음 방법으로 확인됩니다.

참고

이 섹션은 Exchange Server 2003 SP2를 실행하는 서버의 스팸 방지 처리에 대한 정보를 제공하기 위해 업데이트되었습니다. 이 예제에서는 Exchange Server 2003 SP2가 게이트웨이 컴퓨터에 설치되어 있다고 가정합니다.

  1. SMTP 클라이언트는 SMTP 가상 서버에 연결을 시도합니다.
  2. SMTP 가상 서버의 IP 제한(SMTP 가상 서버 속성액세스 탭에서 구성)에 대해 연결 클라이언트의 IP 주소를 확인합니다.
    • 연결 IP 주소가 제한 IP 목록에 있으면 바로 연결이 끊깁니다.
    • 연결 IP 주소가 제한 IP 목록에 없으면 연결이 허용됩니다.
  3. SMTP 클라이언트는 EHLO 또는 HELO 명령을 보냅니다.
  4. SMTP 클라이언트는 다음과 같은 MAIL FROM: 명령을 실행합니다.
    MAIL FROM: dylanm@contoso.com
  5. 전체 수락 목록(메시지 배달 속성 대화 상자의 연결 필터링 탭에 있는 Exchange System Manager에서 구성)에서 SMTP 클라이언트의 IP 주소가 있는지 확인합니다.
    • 연결 IP 주소가 전체 수락 목록에 있으면 전체 거부 목록을 확인하지 않습니다. 7단계로 계속 진행합니다.
    • 연결 IP 주소가 전체 수락 목록에 없으면 6단계 및 7단계를 수행합니다.
  6. 전체 거부 목록(메시지 배달 속성 대화 상자의 연결 필터링 탭에 있는 Exchange System Manager에서 구성)에서 SMTP 클라이언트의 IP 주소가 있는지 확인합니다.
    • SMTP 클라이언트의 IP 주소가 전체 거부 목록에 있으면 연결이 끊깁니다.
    • SMTP 클라이언트의 IP 주소가 전체 거부 목록에 없으면 세션이 계속됩니다.
  7. 보낸 사람 필터링은 차단할 보낸 사람 목록(메시지 배달 속성 대화 상자의 보낸 사람 필터링 탭에 있는 Exchange System Manager에서 구성)에서 MAIL FROM 명령에 지정된 보낸 사람이 있는지 확인합니다.
    • 보낸 사람이 차단할 보낸 사람 목록에 있으면 보낸 사람 필터링이 구성된 방법에 따라 다음 둘 중 하나가 발생합니다.
      - 보낸 사람 필터링이 연결을 끊도록 구성되어 있으면 연결이 끊깁니다.
      - 보낸 사람에게 알리지 않고 메시지를 수락하도록 보낸 사람 필터링을 구성하면 세션은 계속되지만 메일은 Badmail 디렉터리에 보내지고 의도한 받는 사람에게는 전달되지 않습니다.
    • 보낸 사람이 보낸 사람 필터링 목록에 없으면 SMTP 가상 서버에서는 다음과 같은 응답을 내보냅니다.
      250 2.1.0 dylanm@contoso.com...Sender OK
  8. 연결 SMTP 서버는 다음과 같은 RCPT TO 명령을 보냅니다.
    RCPT TO: kim@example.com
  9. 연결 필터 규칙은 차단 목록 서비스 공급자가 제공하는 모든 차단 목록에 대해 연결 IP 주소를 확인합니다.
    • SMTP 클라이언트의 IP 주소가 수락 목록에 있으면 연결 필터 규칙이 무시됩니다. 10단계로 계속 진행합니다.
    • SMTP 클라이언트의 IP 주소가 차단 목록 서비스 공급자의 차단 목록에 있으면 SMTP 가상 서버가 오류 코드를 반환한 후 연결 필터 규칙에 대해 구성된 사용자 지정 오류 메시지를 보냅니다.
    • SMTP 클라이언트의 IP 주소가 차단 목록 서비스 공급자의 차단 목록에 없으면 세션이 계속됩니다.
  10. 연결 필터링은 의도한 받는 사람이 연결 필터링 예외 목록에 있는지 확인합니다.
    • 받는 사람이 이 목록에 있으면 통신이 수락되고 더 이상 RCPT TO 명령에 다른 확인을 적용하지 않습니다. 13단계로 계속 진행합니다.
    • 받는 사람이 예외 목록에 없으면 다른 필터와 대조하여 확인됩니다.
  11. 받는 사람이 연결 필터링에서 구성된 예외 목록에 없으면 받는 사람 필터링에서 구성된 모든 차단할 받는 사람에 대해 확인합니다.
    • 받는 사람이 차단할 받는 사람이면 SMTP 가상 서버가 잘못된 받는 사람 오류를 반환합니다.
    • 받는 사람이 차단할 받는 사람이 아니면 세션이 계속됩니다.
  12. 받는 사람이 차단할 받는 사람이 아니면 Active Directory에 있는지 확인합니다.
    • 의도한 받는 사람이 Active Directory에 있는 올바른 받는 사람이 아니면 SMTP 가상 서버가 잘못된 받는 사람 오류를 반환합니다.
    • 받는 사람이 Active Directory에 있는 올바른 받는 사람이면 세션이 계속됩니다.
  13. RCPT TO 명령에서 추가 지정한 각 받는 사람에 대해서는 10 12단계가 적용됩니다.
  14. 그런 다음 연결 서버는 다음과 같은 DATA 명령을 발급합니다.
    DATA
    To: Kim Akers
    From: dylanm@contoso.com<Dylan Miller>
    Subject: Mail Message
  15. 그런 다음 보낸 사람 필터링은 From 주소가 차단할 보낸 사람과 일치하지 않는지 확인합니다.
    • DATA 명령에 지정된 보낸 사람이 차단할 보낸 사람이면 다음 둘 중 하나가 발생합니다.
      - 받는 사람 필터링이 연결을 끊도록 구성되어 있으면 SMTP 가상 서버에서는 5.1.0 “Sender Denied” 오류를 반환하고 연결을 끊습니다.
      - 보낸 사람에게 알리지 않고 메시지를 수락하도록 보낸 사람 필터링을 구성하면 세션은 계속되지만 메일은 Badmail 디렉터리에 보내지고 의도한 받는 사람에게는 전달되지 않습니다.
    • DATA 명령에 지정된 보낸 사람이 차단할 보낸 사람이 아니면 메시지가 수락되고 배달 큐에 배치됩니다.
  16. 메시지는 보낸 사람 ID 유효성 검사에 의해 처리됩니다.
  17. 메시지는 지능형 메시지 필터링에 의해 처리됩니다.

SMTP 가상 서버에 대한 전송 제한 기능 개선

Exchange Server 2003에서는 표준 Windows 2000 Server 또는 Windows Server 2003 DACL(임의 액세스 제어 목록)이 있음에도 불구하고 SMTP 가상 서버에 대한 제출을 제한된 수의 보안 원칙으로 제한할 수 있습니다. 이렇게 하면 가상 서버에 메일을 제출할 수 있는 사용자 그룹을 지정할 수 있습니다

참고

인터넷 메일을 받는 SMTP 가상 서버에서 전송을 제한하지 마십시오.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "보안 그룹을 기준으로 SMTP 서버에 대한 전송을 제한하는 방법"을 참조하십시오.

SMTP 가상 서버에 대한 릴레이 제한 기능 개선

Exchange 2003에서는 표준 Windows 2000 DACL(임의의 액세스 제어 목록)이 있음에도 불구하고 릴레이를 제한된 수의 보안 원칙으로 제한할 수 있습니다. 이렇게 하면 가상 서버를 통해 릴레이할 수 있는 사용자 그룹을 지정할 수 있습니다

가상 서버에서 릴레이 제한 기능은 한 사용자 그룹에게 인터넷 메일 릴레이를 허용하고 다른 그룹에 대해서는 릴레이 권한을 거부하려는 경우 유용합니다.

자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드의 "보안 그룹을 기준으로 릴레이 제한 방법"을 참조하십시오.