재생 디렉터리 관리

아티클
09/30/2014

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2007-02-22

기본적으로 재생 디렉터리는 허브 전송 서버 역할 또는 Edge 전송 서버 역할이 설치된 모든 Microsoft Exchange Server 2007 컴퓨터에 존재합니다. 재생 디렉터리로 복사된 올바른 형식의 전자 메일 메시지 파일은 배달을 위해 전송됩니다. 재생 디렉터리가 외부 게이트웨이 서버에서 메시지를 수신하고 관리자가 Exchange 2007 서버 큐에서 내보내는 메시지를 재전송합니다.

모든 재생 디렉터리 구성 작업에 Set-TransportServer cmdlet를 사용합니다. 이 cmdlet를 사용하여 다음과 같이 재생 디렉터리 구성을 변경할 수 있습니다.

재생 디렉터리를 사용하거나 사용하지 않도록 설정합니다.
재생 디렉터리의 위치를 지정합니다.
최대 메시지 파일 처리 속도를 분당 메시지 개수로 지정합니다.

재생 디렉터리에서 메시지를 처리하는 방법

재생 디렉터리로 복사된 올바른 형식의 .eml 메시지 파일을 전송하기 위한 처리 단계는 다음과 같습니다.

5초마다 재생 디렉터리에 새로운 메시지 파일이 있는지 확인합니다. 이 폴링 간격은 수정할 수 없습니다. Set-TransportServer cmdlet에서 PickupDirectoryMaxMessagesPerMinute 매개 변수를 사용하여 메시지 파일 처리 속도를 조정할 수 있습니다. 기본값은 분당 100개의 메시지입니다. 열 수 없는 파일은 재생 디렉터리에 남아 있으며 다음 폴링에서 다시 평가됩니다.
파일 이름이 <filename>.eml에서 <filename>.tmp로 바뀝니다. *<filename>.*tmp 파일이 이미 있는 경우 파일 이름이 <filename><datetime>.tmp로 바뀝니다. 파일 이름을 바꾸지 못하는 경우 이벤트 로그 오류가 생성되며 재생 프로세스는 다음 파일로 진행됩니다.
.tmp 파일이 전자 메일 메시지로 변환된 후 "delete on close" 명령을 .tmp 파일에 실행합니다. .tmp 파일이 재생 디렉터리에 남아 있는 것으로 나타나지만 해당 파일을 다른 사용자가 열 수 없습니다.
배달할 메시지를 큐에 넣은 후 "close" 명령을 실행하여 .tmp 파일을 재생 디렉터리에서 삭제합니다. 삭제하지 못하는 경우 이벤트 로그 오류가 생성됩니다. 재생 디렉터리에 .tmp 파일이 있으면 Microsoft Exchange 전송 서비스를 다시 시작하는 경우 모든 .tmp 파일의 이름이 .eml 파일로 바뀌고 다시 처리됩니다. 이로 인해 메시지 전송이 중복될 수 있습니다.

전자 메일 메시지 파일 분석

표준 SMTP 전자 메일 메시지는 메시지 봉투와 메시지 콘텐츠로 구성됩니다. 메시지 봉투에는 메시지를 전송 및 배달하는 데 필요한 정보가 있습니다. 메시지 내용에는 집합적으로 메시지 머리글 및 메시지 본문이라고 하는 메시지 머리글 필드가 들어 있습니다. 메시지 봉투는 RFC 2821에 설명되어 있고 메시지 머리글은 RFC 2822에 설명되어 있습니다.

보낸 사람이 전자 메일 메시지를 작성하여 배달하도록 전송하는 경우 메시지에는 보낸 사람, 받는 사람, 메시지가 작성된 날짜 및 시간, 옵션 제목 줄 및 옵션 메시지 본문 등 SMTP 표준을 준수하는 데 필요한 기본 정보가 포함됩니다. 이러한 정보는 메시지 자체에 포함되어 있으며 정의에 따라 메시지 머리글에 포함되어 있습니다. 보낸 사람의 메시징 서버에서 메시지 머리글에 있는 보낸 사람과 받는 사람 정보를 사용하여 메시지의 메시지 봉투를 생성하고 배달할 수 있도록 인터넷으로 메시지를 전송합니다. 메시지 봉투는 메시지 전송 프로세스에 의해 생성되며 실제로는 메시지의 일부가 아니기 때문에 받는 사람은 메시지 봉투를 볼 수 없습니다. 메시지 전송과 관련된 각 서버는 서버의 배달 역할과 관련된 메시지 머리글 필드나 다른 응용 프로그램 관련 메시지 머리글 필드를 메시지 머리글에 삽입할 수도 있습니다. 받는 사람이 전자 메일 클라이언트를 사용하여 메시지를 열면 전자 메일 클라이언트는 보낸 사람, 받는 사람 및 제목 등 메시지 머리글의 관련 정보를 일부 표시합니다.

메시지 봉투와 메시지 머리글 간의 관계를 설명하려면 규모가 큰 회사에서 일반 우편물을 보내는 것과 비교하는 것이 가장 좋습니다. 편지의 맨 위 인사말에 회사 주소와 받는 사람 주소가 있는 공식적인 비즈니스 레터를 작성합니다. 이 편지를 처리하려면 회사의 우편물 보관실로 보냅니다. 우편물 보관실 직원은 편지에 있는 받는 사람 정보를 사용하여 봉투를 만들고, 봉투에 편지를 넣어 봉한 다음, 배달하도록 사서함에 넣습니다. 우체국에서는 봉투에 있는 주소에 따라 받는 사람의 회사로 봉투를 배달합니다. 받는 사람 회사의 우편물 보관실 직원은 봉투를 받아, 봉투에 씌여 있는 받는 사람을 확인한 다음, 봉투를 열어, 받는 사람의 개인 사서함에 편지를 놓습니다. 받는 사람이 개인 사서함에서 편지를 가져오면 인사말의 정보를 통해 편지를 작성한 사람과 편지를 받을 사람이 자신인지 알 수 있습니다.

재생 디렉터리의 메시지 파일 요구 사항

재생 디렉터리는 내보낸 Exchange 메시지를 다시 전송하고 외부 게이트웨이 서버의 메시지를 수신하는 데 사용됩니다. 이러한 메시지는 이미 재생 디렉터리에 맞는 형식으로 되어 있습니다. 관리자 또는 다른 응용 프로그램에서 재생 디렉터리를 사용하여 새로운 메시지 파일을 작성하거나 전송할 필요가 거의 또는 전혀 없습니다. 픽업 디렉터리는 새로운 메시지 파일을 만들고 전송하는 데 사용되어야 합니다.

재생 디렉터리 메시지는 X-Header를 포괄적으로 사용합니다. X-Header는 사용자가 정의하며 메시지 머리글에 있는 비공식적인 메시지 머리글 필드입니다. X-Header는 RFC 2822에 구체적으로 언급되어 있지 않지만 "X-"로 시작하는 정의되지 않은 메시지 머리글 필드를 사용하여 메시지에 비공식적인 메시지 머리글 필드를 추가할 수 있습니다. 재생 디렉터리의 메시지 파일에 사용되는 Exchange 2007 관련 X-Header는 실제로 메시지 봉투에 있는 배달 정보를 설정할 수 있습니다. 이 기능은 재생 디렉터리를 사용하여 다른 Exchange 서버에서 내보낸 메시지를 처리하는 경우 원본 메시지 정보를 유지하는 데 필요합니다.

재생 디렉터리로 복사된 메시지 파일을 배달하기 위해 충족시켜야 하는 요구 사항은 다음과 같습니다.

메시지 파일은 기본 SMTP 메시지 형식을 따르는 텍스트 파일이어야 합니다. MIME(Multipurpose Internet Mail Extensions) 메시지 머리글 필드와 내용은 지원됩니다.
메시지 파일의 파일 이름 확장명은 .eml이어야 합니다.
X-Header는 모든 일반 헤더 필드 전에 발생해야 합니다.
헤더 필드와 메시지 본문 사이에는 빈 줄이 있어야 합니다.

다음 목록에 설명되어 있는 X-Header는 재생 디렉터리의 메시지에 필요합니다.

X-Sender: 이 X-Header는 일반적인 SMTP 메시지의 From: 메시지 머리글 필드 요구 사항을 대신합니다. 하나의 전자 메일 주소가 포함된 하나의 X-Sender: 필드가 있어야 합니다. 받는 사람의 전자 메일 클라이언트가 From: 메시지 머리글 필드의 값을 메시지의 보낸 사람으로 표시하지만 재생 디렉터리는 From: 메시지 머리글 필드가 있는 경우 이를 무시합니다. 다른 매개 변수는 일반적으로 다음 예에 표시된 것처럼 X-Sender: 필드에 있습니다.
```
X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
```
참고

이러한 매개 변수는 보내는 서버에서 일반적으로 생성되는 메시지 봉투 값입니다. 내보낸 메시지 파일에서 이와 유사한 매개 변수를 볼 수도 있습니다.
RET=는 메시지를 배달할 수 없는 경우 전체 메시지를 보낸 사람에게 반환할 것인지 또는 헤더만 보낸 사람에게 반환할 것인지 지정합니다. RET= 값은 HDRS 또는 FULL입니다.
ENVID=는 메시지 봉투 식별자입니다. BODY=는 메시지의 텍스트 인코딩을 지정합니다. AUTH=는 RFC 2554에 설명되어 있는 대로 메시징 서버에 대한 인증 메커니즘을 지정합니다.
X-Receiver: 이 X-Header는 일반적인 SMTP 메시지의 To: 메시지 머리글 필드 요구 사항을 대신합니다. 하나의 전자 메일 주소가 포함된 X-Receiver: 필드가 한 개 이상 있어야 합니다. 여러 X-Receiver: 필드가 여러 받는 사람에 대해 허용됩니다. 받는 사람의 전자 메일 클라이언트가 To: 메시지 머리글 필드의 값을 메시지의 받는 사람으로 표시하지만 재생 디렉터리는 To: 메시지 머리글 필드가 있는 경우 이를 무시합니다. 다른 옵션 매개 변수가 다음 예에 표시된 것처럼 X-Receiver: 필드에 있을 수 있습니다.
```
X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
```
참고

이러한 매개 변수는 보내는 서버에서 일반적으로 생성되는 메시지 봉투 값입니다. 내보낸 메시지 파일에서 이와 유사한 매개 변수를 볼 수도 있습니다. 이러한 매개 변수는 RFC 1891에 설명되어 있는 것처럼 DSN(배달 상태 알림) 메시지와 관련이 있습니다. NOTIFY=의 값은 NEVER, DELAY 또는 FAILURE가 될 수 있습니다. ORcpt=를 사용하여 원래 메시지 받는 사람을 유지합니다.

다음 목록에 설명되어 있는 X-Header는 재생 디렉터리의 메시지 파일 선택 사항입니다.

X-CreatedBy: 이 X-Header가 있는 경우 비어 있으면 안 됩니다. X-CreatedBy: 필드가 없는 경우 이 필드는 Unspecified 값으로 추가됩니다. 일반적으로 이 필드의 값은 MSExchange12이지만 송신 커넥터에 설정된 비 SMTP 주소 공간 유형을 포함할 수도 있습니다(예: Notes). 이 메시지 머리글 필드는 머리글 방화벽 기능에 사용됩니다.
X-EndOfInjectedXHeaders: 존재하는 모든 X-Header의 크기(바이트)입니다. 이 X-Header는 일반 메시지 머리글 필드가 시작되기 전에 마지막 X-Header를 나타내는 표시로 사용될 수도 있습니다.
X-ExtendedMessageProps: 메시지의 확장 메시지 속성입니다.
X-HeloDomain: 초기 SMTP 프로토콜 대화 중에 나타나는 HELO/EHLO 도메인 문자열입니다.
X-LegacyExch50: Exchange 2003 서버가 있는 경우 Exchange Server 2003에서 생성되는 사용자 지정 속성을 유지하는 데 사용됩니다.
X-Source: 이 X-Header의 값이 지정되지 않은 경우 Replay의 값이 사용됩니다. 이 X-Header는 MessageSourceName 열 아래의 큐 뷰어에서 사용됩니다. 이 X-Header의 다른 가능한 값은 Smtp Receive Connector 및 Smtp Send Connector입니다.
X-SourceIPAddress: 보내는 서버의 IP 주소입니다. IP 주소가 지정되지 않은 경우 이 필드는 0.0.0.0입니다.

다음은 재생 디렉터리에 대해 적합한 형식을 사용하는 일반 텍스트 메시지의 예입니다.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject

This is the body of the message.

MIME 콘텐츠도 재생 디렉터리 메시지 파일에서 지원됩니다. MIME는 7비트 ASCII 텍스트, HTML 및 기타 멀티미디어 콘텐츠로 나타낼 수 없는 언어를 포함하여 광범위한 메시지 내용을 정의합니다. MIME에 대한 자세한 정보과 해당 요구 사항은 이 항목의 범위를 벗어납니다. 다음은 재생 디렉터리에 적합한 형식을 사용하는 간단한 MIME 메시지의 예입니다.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@contoso.com
Subject: Optional message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>

</BODY></HTML>

재생 디렉터리의 메시지 파일에 만들어진 메시지 머리글에 대한 수정

재생 디렉터리는 메시지 파일에서 Bcc: 메시지 머리글 필드를 삭제합니다.

재생 디렉터리는 메시지 전송 프로세스의 일부로 자체 Received: 메시지 머리글 필드를 메시지에 추가합니다. Received: 메시지 머리글 필드는 다음과 같은 형식으로 적용됩니다.

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

재생 디렉터리는 메시지 머리글에서 다음 메시지 머리글 필드를 수정합니다.

Message-ID: 이 메시지 머리글 필드가 없거나 비어 있는 경우 재생 디렉터리는 <GUID>@<defaultdomain> 형식을 사용하여 Message-ID: 메시지 머리글 필드를 추가합니다.
Date: 이 메시지 머리글 필드가 없거나 해당 형식이 잘못된 경우 재생 디렉터리는 재생 디렉터리의 메시지 처리 날짜 및 시간을 사용하여 Date: 메시지 머리글 필드를 추가합니다.

재생 디렉터리 메시지 처리 실패

메시지 파일을 전자 메일 메시지로 변환하는 데 문제가 있으면 재생 디렉터리에서 해당 메시지를 배달할 수 없는 메일(Badmail)로 간주하게 됩니다. Badmail 메시지 파일은 보낸 사람 누락, 받는 사람 누락 또는 형식 문제와 같은 문제를 가지고 있습니다. Badmail로 결정된 메시지 파일은 재생 디렉터리에 남아 있으며 <filename>.eml에서 <filename>.bad로 이름이 바뀝니다. <filename>.bad 파일이 이미 있는 경우 해당 파일의 이름이 <filename><datetime>.bad로 바뀝니다. 재생 디렉터리에 Badmail이 있는 경우 이벤트 로그 오류가 생성되지만 동일한 Badmail 메시지가 반복적인 이벤트 로그 오류를 생성하지는 않습니다.

재생 디렉터리의 보안 문제

Exchange Server 2003은 텍스트 메시지 파일을 만들고 전송하기 위해 단일 픽업 디렉터리를 사용합니다. Exchange 2007에서는 이 기능을 별도의 픽업 디렉터리와 재생 디렉터리로 분할합니다. 픽업 디렉터리는 새로운 메시지 파일을 수동으로 만드는 사용자나 응용 프로그램을 위한 것입니다. 재생 디렉터리는 내보낸 Exchange 전자 메일 메시지를 다시 전송하고 비 SMTP 커넥터의 메시지를 받기 위한 것입니다. 이렇게 기능을 분리하면 한 디렉터리의 기능에 영향을 주지 않으면서 다른 디렉터리에 적절한 보안을 적용할 수 있습니다.

다음 목록에는 픽업 디렉터리 및 재생 디렉터리에 대한 일반적인 보안 문제가 설명되어 있습니다.

스팸 방지, 바이러스 백신, 보낸 사람 필터링 또는 받는 사람 필터링 작업 등 수신 커넥터에 구성된 모든 보안 검사가 메시지 제출 시 픽업 디렉터리 및 재생 디렉터리를 통해 전송되는 메시지에 대해서는 수행되지 않습니다.
노출된 픽업 디렉터리나 재생 디렉터리는 오픈 릴레이로 작동할 수 있습니다. 이렇게 되면 실제 메시지 원본을 마스크하도록 다른 서버를 사용하여 메시지를 다시 전송하거나 "릴레이"할 수 있습니다.

다음 목록에서는 재생 디렉터리에 적용되는 추가 보안 문제에 대해 설명합니다.

재생 디렉터리에서 사용되는 X-Header로 메시지 봉투를 수동으로 만들 수 있습니다. X-Sender: 및 X-Receiver: 필드의 정보가 전자 메일 클라이언트에 표시된 To: 또는 From: 메시지 머리글 필드와 완전히 다를 수 있습니다. 이러한 보낸 사람 및 도메인에 대한 가장을 일반적으로 스푸핑이라고 합니다. 위장된 메일은 실제로 메시지를 보내지 않은 사람이 전자 메일 메시지를 보낸 것처럼 보이도록 주소가 수정된 전자 메일 메시지입니다.
X-CreatedBy: 필드의 값이 MSExchange12인 경우 대상을 신뢰할 수 있다고 간주하고 헤더 방화벽을 적용하지 않습니다. 헤더 방화벽은 Exchange에서 신뢰된 Exchange 2007 서버 간에 전송된 메시지의 X-Header를 유지하거나 Exchange 조직 외부의 신뢰할 수 없는 대상으로 전송된 메시지에서 잠재적으로 나타날 수 있는 X-Header를 제거하는 방법입니다. 이러한 X-Header를 사용하여 SCL(스팸 지수), 메시지 서명 또는 인증된 Exchange 2007 서버 간 암호화 등의 Exchange 2007 정보를 공유할 수 있습니다. 이러한 정보를 인증되지 않은 소스에 공개하는 것은 잠재적 보안 위험을 내포할 수 있습니다.

픽업 디렉터리 및 재생 디렉터리의 구분은 각 디렉터리에 다른 보안 수준을 적용할 수 있다는 의미입니다. 재생 디렉터리와 관련된 추가 보안 위험으로 인해 재생 디렉터리에는 더 강력한 보안이 적용되어야 합니다. 새로운 메시지를 생성하고 전송해야 하는 사용자나 응용 프로그램은 픽업 디렉터리에 대한 액세스 권한을 부여받을 수 있으며 재생 디렉터리에 대한 액세스가 필요하지 않습니다.

재생 디렉터리의 권한

재생 디렉터리에 다음 권한이 필요합니다.

관리자: 모든 권한
시스템: 모든 권한
네트워크 서비스: 하위 폴더 및 파일의 읽기, 쓰기 및 삭제

기본적으로 Microsoft Exchange 전송 서비스는 네트워크 서비스 사용자 계정의 보안 자격 증명을 사용하여 재생 디렉터리의 위치 및 권한을 관리합니다. 네트워크 서비스 계정은 재생 디렉터리에서 이러한 권한이 있어야 .eml 파일을 열고, .tmp로 이름을 바꾸어 삭제하거나, 메시지가 Badmail로 분류되는 경우 .bad로 이름을 바꿀 수 있습니다.

Set-TransportServer cmdlet에서 ReplayDirectoryPath 매개 변수를 사용하여 재생 디렉터리의 위치를 이동할 수 있습니다. 재생 디렉터리의 위치 변경 성공은 새로운 재생 디렉터리에서 네트워크 서비스 계정에 부여된 권한과 새로운 재생 디렉터리가 이미 존재하는지 여부에 따라 달라집니다. 새 재생 디렉터리가 아직 없고 네트워크 서비스 계정이 폴더를 만들고 새 위치에 권한을 적용하는 데 필요한 권한을 가지고 있는 경우 새 재생 디렉터리가 생성되고 올바른 권한이 재생 디렉터리에 적용됩니다. 새 재생 디렉터리가 이미 있는 경우 기존 폴더 권한을 확인하지 않습니다. Set-TransportServer cmdlet를 통해 ReplayDirectoryPath 매개 변수를 사용하여 재생 디렉터리를 이동할 때마다 새 재생 디렉터리가 있고 새 디렉터리에 올바른 권한이 적용되었는지 항상 확인하는 것이 좋습니다. 재생 디렉터리에 대한 변경을 실패한 경우 ReplayDirectoryPath 매개 변수를 Set-TransportServer cmdlet와 함께 사용하기 전에 새로운 재생 디렉터리를 만들어 올바른 권한을 적용할 수 있습니다.

자세한 내용

자세한 내용은 다음 항목을 참조하십시오.

다음을 통해 공유