Exchange Server: Edge 전송 서버에서 주소 다시 쓰기

Exchange Server 주소 다시 쓰기는 Edge 전송 서버를 통해 조직을 입력하거나 나가는 메시지에서 보낸 사람과 받는 사람의 이메일 주소를 수정합니다. Edge 전송 서버에서 다시 쓰기 기능을 제공하는 두 전송 에이전트는 주소 다시 쓰기 인바운드 에이전트와 주소 다시 쓰기 아웃바운드 에이전트입니다. 아웃바운드 메시지의 경우 기본적으로 외부 받는 사람에게 일관된 단일 전자 메일 도메인을 표시하기 위해 주소를 다시 씁니다. 인바운드 메시지의 경우에는 기본적으로 올바른 받는 사람에게 메시지를 배달하기 위해 주소를 다시 씁니다.

만드는 주소 다시 쓰기 항목은 내부 주소(변경할 전자 메일 주소) 및 외부 주소(원하는 최종 전자 메일 주소)를 지정합니다. 전자 메일 주소를 다시 쓸 메시지(인바운드 및 아웃바운드 메시지 또는 아웃바운드 메시지만)를 지정할 수 있습니다. 단일 사용자(chris@contoso.com to support@contoso.com), 단일 도메인(fabrikam.com contoso.com) 또는 예외가 있는 여러 하위 도메인에 대한 주소 쓰기 항목을 만들 수 있습니다(*.fabrikam.com contoso.com(legal.fabrikam.com 제외).

중요

주소 다시 쓰기를 사용하려는 방법에 관계없이 주소가 중복되지 않도록 다시 쓰기를 통해 생성되는 전자 메일 주소가 조직에서 고유한지를 확인해야 합니다. 주소 다시 쓰기는 다시 작성된 전자 메일 주소의 고유성을 확인하지 않습니다.

중요

DKIM 서명은 주소 다시 쓰기 프로세스 전에 발생하는 대로 다시 작성된 주소를 사용하는 아웃바운드 전자 메일 메시지에 대해 지원되지 않습니다. 조직에서 아웃바운드 전자 메일에 DKIM 서명이 필요한 경우 주소 다시 쓰기를 구현한 후 DKIM 유효성 검사가 실패합니다.

주소 다시 쓰기를 구성하려면 Edge 전송 서버의 주소 다시 쓰기 절차를 참조하세요.

주소 다시 쓰기 시나리오

다음 시나리오는 주소 다시 쓰기를 사용할 수 있는 방법의 예입니다.

  • 그룹 통합: 일부 조직은 내부 비즈니스를 비즈니스 또는 기술 요구 사항에 따라 별도의 도메인으로 분할합니다. 이러한 구성으로 인해 전자 메일 메시지가 별도의 그룹 또는 별도의 조직에서 보낸 것처럼 표시될 수 있습니다.

    다음 예에서는 Contoso, Ltd. 조직이 내부 하위 도메인을 외부 받는 사람이 볼 수 없도록 숨기는 방법을 보여 줍니다.

    • northamerica.contoso.com, europe.contoso.com 및 asia.contoso.com 도메인에서 보내는 아웃바운드 메시지를 다시 써서 단일 도메인 contoso.com에서 보내는 것으로 표시되도록 합니다. 모든 메시지는 전체 조직과 인터넷 간에 SMTP 연결을 제공하는 Edge 전송 서버를 통과할 때 다시 쓰여집니다.

    • contoso.com 받는 사람에게 보내는 인바운드 메시지는 Edge 전송 서버에 의해 사서함 서버로 릴레이됩니다. 메시지는 받는 사람의 사서함에 구성된 프록시 주소를 기준으로 올바른 받는 사람에게 배달됩니다.

  • 인수 합병: 인수된 회사는 별도의 비즈니스로 계속 운영될 수 있지만 주소 다시 쓰기를 사용하여 두 조직이 하나의 통합 조직인 것처럼 표시되도록 할 수 있습니다.

    다음 예에서는 Contoso, Ltd.가 새로 인수한 회사 Fourth Coffee의 전자 메일 도메인을 숨기는 방법을 보여 줍니다.

    • Contoso, Ltd.는 Fourth Coffee Exchange 조직의 모든 아웃바운드 메시지가 contoso.com 온 것처럼 표시되기를 원합니다. 두 조직의 모든 메시지는 Contoso, Ltd.의 Edge 전송 서버를 통해 전송되며, 여기서 전자 메일 메시지는 user@fourthcoffee.com user@contoso.com 다시 작성됩니다.

    • user@contoso.com 대한 인바운드 메시지는 다시 작성되어 user@fourthcoffee.com 사서함으로 라우팅됩니다. user@fourthcoffee.com 전송되는 인바운드 메시지는 Fourth Coffee의 전자 메일 서버로 직접 라우팅됩니다.

  • 파트너: 많은 조직에서 외부 파트너를 사용하여 고객, 다른 조직 또는 자체 조직에 서비스를 제공합니다. 이러한 경우 혼란을 피하려면 파트너 조직의 전자 메일 도메인을 자체 조직의 전자 메일 도메인으로 대체해야 합니다.

    다음 예에서는 Contoso, Ltd.가 파트너의 전자 메일 도메인을 숨기는 방법을 보여 줍니다.

    • Contoso, Ltd.는 보다 큰 규모의 Wingtip Toys 조직에 지원을 제공합니다. Wingtip Toys는 고객에게 통합된 전자 메일 환경을 제공하고자 하며, Contoso, Ltd.의 지원 담당자가 보내는 모든 메시지가 Wingtip Toys에서 전송된 것처럼 표시해야 합니다. Wingtip Toys와 관련된 모든 아웃바운드 메시지는 Wingtip Toys의 Edge 전송 서버를 통해 전송되며 모든 contoso.com 전자 메일 주소를 wingtiptoys.com 전자 메일 주소로 다시 씁니다.

    • 에 대한 support@wingtiptoys.com 인바운드 메시지는 Wingtip Toy의 Edge 전송 서버에서 수락하고, 다시 작성한 다음, 이메일 주소로 support@contoso.com 라우팅됩니다.

주소 다시 쓰기를 통해 수정되는 메시지 속성

표준 SMTP 전자 메일 메시지는 메시지 봉투 및 메시지 콘텐츠로 구성됩니다. 메시지 봉투에는 SMTP 메시징 서버 간에 메시지를 전송하고 전달하는 데 필요한 정보가 포함되어 있습니다. 메시지 콘텐츠에는 메시지 헤더 필드(전체적으로 메시지 헤더라고 함) 및 메시지 본문이 포함됩니다. 메시지 봉투는 RFC 2821에 설명되어 있고 메시지 헤더는 RFC 2822에 설명되어 있습니다.

보낸 사람이 전자 메일 메시지를 작성하고 배달을 위해 제출하는 경우 메시지에는 보낸 사람, 받는 사람, 메시지를 작성한 날짜 및 시간, 선택적 제목 줄 및 선택적 메시지 본문과 같은 SMTP 표준을 준수하는 데 필요한 기본 정보가 포함됩니다. 이러한 정보는 메시지 자체에 포함되어 있으며 정의에 따라 메시지 헤더에 있습니다.

보낸 사람의 메일 서버에서 메시지 헤더에 있는 보낸 사람과 받는 사람 정보를 사용하여 메시지의 메시지 봉투를 생성합니다. 그런 다음 수신자의 메시징 서버로 배달하기 위해 메시지를 인터넷으로 전송합니다. 메시지 봉투는 메시지 전송 프로세스에 의해 생성되며 실제로는 메시지의 일부가 아니기 때문에 받는 사람은 메시지 봉투를 볼 수 없습니다.

주소 다시 쓰기에서는 메시지 헤더 또는 메시지 봉투의 특정 필드를 다시 써서 전자 메일 주소가 변경됩니다. 주소 다시 쓰기는 아웃바운드 메시지의 여러 필드를 변경하지만 인바운드 전자 메일 메시지에는 하나의 필드만 변경합니다. 다음 표에는 아웃바운드 메시지와 인바운드 메시지에서 다시 쓰여지는 SMTP 헤더 필드가 나와 있습니다.

아웃바운드 및 인바운드 메시지에서 메시지 필드를 다시 작성합니다.

필드 이름 위치 아웃바운드 메시지 인바운드 메시지
메일 원본 메시지 봉투 재 작 성 다시 작성 안 했습니다.
RCPT TO 메시지 봉투 다시 작성 안 했습니다. 재 작 성
To 메시지 헤더 다시 작성 안 했습니다. 재 작 성
Cc 메시지 헤더 재 작 성 재 작 성
시작 메시지 헤더 재 작 성 다시 작성 안 했습니다.
보낸 사람 메시지 헤더 재 작 성 다시 작성 안 했습니다.
회신 메시지 헤더 재 작 성 다시 작성 안 했습니다.
Return-Receipt-To 메시지 헤더 재 작 성 다시 작성 안 했습니다.
처리 알림-To 메시지 헤더 재 작 성 다시 작성 안 했습니다.
Resent-From 메시지 헤더 재 작 성 다시 작성 안 했습니다.
Resent-Sender 메시지 헤더 재 작 성 다시 작성 안 했습니다.

주소 다시 쓰기에서 변경되지 않는 항목

주소 다시 쓰기에서는 수정 시 SMTP 기능이 중단되는 메시지 헤더 필드는 수정하지 않습니다. 예를 들어 특정 헤더 필드를 수정하면 라우팅 루프 검색에 영향을 주거나, 디지털 서명을 무효화하거나, 권한으로 보호된 메시지를 읽을 수 없게 만들 수 있습니다. 따라서 다음과 같은 헤더 필드는 주소 다시 쓰기를 통해 수정되지 않습니다.

  • Return-Path

  • Received

  • Message-ID

  • X-MS-TNEF-Correlator

  • Content-Type Boundary=string

  • MIME 본문 부분 내부에 있는 헤더 필드

주소 다시 쓰기에서는 Exchange 조직에서 제어하지 않는 도메인을 무시합니다. 즉, 도메인은 Exchange 조직에서 신뢰할 수 있는 허용 도메인으로 구성되어야 합니다. 신뢰할 수 없는 도메인을 다시 작성하면 제어할 수 없는 형태의 메시지 릴레이가 발생합니다.

또한 주소 다시 쓰기에서는 다른 메시지에 포함되어 있는 메시지의 헤더 필드를 수정하지 않습니다. 보낸 사람과 받는 사람은 메시지가 보낸 사람과 받는 사람 간에 구현되는 메일 흐름 규칙(전송 규칙이라고도 함)을 트리거하지 않는 한 포함된 메시지가 그대로 유지되고 수정 없이 배달될 것으로 예상합니다.

아웃바운드 전용 주소 다시 쓰기 관련 고려 사항

Edge 전송 서버에서 아웃바운드 전용 주소 다시 쓰기는 메시지가 Exchange 조직을 떠날 때 보낸 사람의 이메일 주소를 수정합니다. 단일 사용자(에서 )에 대해 또는 단일 도메인(chris@contoso.com fabrikam.com contoso.com support@contoso.com)에 대해 아웃바운드 전용 주소 다시 쓰기를 구성할 수 있습니다. 여러 하위 도메인에 대해 아웃바운드 전용 주소 다시 쓰기를 구성해야 합니다(*.fabrikam.com contoso.com).

다시 작성된 전자 메일 주소는 영향을 받는 받는 사람에 대한 프록시 주소로 구성해야 합니다. 예를 들어 이 로 laura@contoso.com다시 작성되면 laura@sales.contoso.com 프록시 주소를 laura@contoso.com Laura의 사서함에 구성해야 합니다. 이렇게 하면 회신 및 인바운드 메시지가 올바르게 배달됩니다.

인바운드 및 아웃바운드 주소 다시 쓰기 관련 고려 사항

Edge 전송 서버에서 인바운드 및 아웃바운드 또는 양방향 주소 다시 쓰기는 메시지가 Exchange 조직을 떠날 때 보낸 사람의 전자 메일 주소를 수정하고 메시지가 Exchange 조직에 들어갈 때 받는 사람의 전자 메일 주소를 수정합니다.

단일 사용자(에서 ) 및 단일 도메인(chris@contoso.comsupport@contoso.comfabrikam.com contoso.com)에 대한 양방향 주소 다시 쓰기를 구성할 수 있습니다. 여러 하위 도메인에 대해 양방향 주소 다시 쓰기를 구성할 수 없습니다(*.fabrikam.com contoso.com).

여러 도메인의 전자 메일 주소 다시 쓰기 관련 고려 사항

여러 내부 도메인 또는 하위 도메인을 단일 외부 도메인으로 평면화할 때는 다음 요인을 고려해야 합니다.

  • 고유 별칭 확인: 모든 전자 메일 별칭(@ 기호 왼쪽 부분)은 모든 하위 도메인에서 고유해야 합니다. 예를 들어 가 있는 joe@sales.contoso.com경우 두 사용자에 대해 다시 작성된 전자 메일 주소가 가 되므로 이 있을 joe@marketing.contoso.comjoe@contoso.com수 없습니다.

  • 프록시 주소 추가: 영향을 받는 도메인의 영향을 받는 모든 보낸 사람에서 다시 작성된 전자 메일 주소를 프록시 주소로 구성해야 합니다. 예를 들어 를 로 joe@contoso.com다시 작성하는 경우 joe@sales.contoso.com 프록시 주소를 joe@contoso.com Joe의 사서함에 추가해야 합니다. 이렇게 하면 회신 및 인바운드 메시지가 올바르게 배달됩니다.

  • 비 Exchange 조직의 메일 연락처: Exchange가 아닌 전자 메일 시스템에서 전자 메일 주소를 다시 작성하는 경우 Exchange에서 메일 연락처를 만들어 Exchange가 아닌 전자 메일 시스템의 사용자를 나타내야 합니다. 이러한 전자 메일 연락처에는 원래 전자 메일 주소와 다시 작성된 전자 메일 주소가 포함되어야 합니다. 예를 들어 를 로 joe@contoso.com다시 작성하는 경우 joe@unix.contoso.com 와 메일 연락처 joe@unix.contoso.com 를 외부 전자 메일 주소로, joe@contoso.com 프록시 주소로 만들어야 합니다.

고유한 별칭 확인

여러 하위 도메인의 전자 메일 주소를 다시 쓸 때는 모든 전자 메일 별칭이 모든 하위 도메인에서 고유한지 확인해야 합니다. 예를 들어 다음 구성을 검토해 보겠습니다.

다음 사용자는 하위 도메인 sales.contoso.com, marketing.contoso.com 및 research.contoso.com에 있습니다.

  • maria@sales.contoso.com

  • chris@sales.contoso.com

  • david@marketing.contoso.com

  • brian@marketing.contoso.com

  • chris@research.contoso.com

  • adam@research.contoso.com

하위 도메인 sales.contoso.com, marketing.contoso.com 및 research.contoso.com을 단일 도메인 contoso.com으로 다시 쓴다고 가정하겠습니다.

각 하위 도메인의 전자 메일 주소를 다시 작성하면 두 전자 메일 주소가 로 다시 작성chris@contoso.com되기 때문에 와 chris@research.contoso.com사이에 chris@sales.contoso.com 충돌이 발생합니다. 이 문제를 해결하려면 영향을 받는 받는 사람 중 하나의 이메일 주소를 변경해야 합니다. 예를 들어 전자 메일 주소를 로 christopher@research.contoso.com 다시 작성하도록 을 christopher@contoso.com로 변경할 chris@research.contoso.com 수 있습니다.

주소 다시 쓰기 항목의 우선 순위

사용자의 전자 메일 주소가 여러 주소 다시 쓰기 항목과 일치하는 경우에는 가장 근접한 일치 항목을 기준으로 전자 메일 주소를 한 번만 다시 씁니다. 다음 목록에서는 주소 다시 쓰기 항목의 우선 순위 순서를 가장 높은 우선 순위부터 차례로 설명합니다.

  1. 개별 전자 메일 주소: 의 이메일 주소를 로 다시 작성하도록 주소 다시 쓰기 항목이 john@contoso.comsupport@contoso.com구성됩니다.

  2. 도메인 또는 하위 도메인 매핑: 주소 다시 쓰기 항목은 모든 contoso.com 전자 메일 주소를 northwindtraders.com 다시 작성하거나 contoso.com 모든 sales.contoso.com 전자 메일 주소를 다시 작성하도록 구성됩니다.

  3. 도메인 평면화: *.contoso.com 전자 메일 주소를 다시 작성하여 contoso.com 주소 다시 쓰기 항목이 구성됩니다.

예를 들어 Edge 전송 서버에서 다음 아웃바운드 주소 다시 쓰기 항목이 구성되어 있다고 가정해 보겠습니다.

  • *.contoso.com 전자 메일 주소는 contoso.com 다시 작성됩니다.

  • japan.sales.contoso.com 전자 메일 주소를 contoso.jp로 다시 씁니다.

전자 메일 메시지를 보내는 경우 masato@japan.sales.contoso.com 해당 항목이 보낸 사람의 전자 메일 주소와 가장 밀접하게 일치하기 masato@contoso.jp때문에 주소가 로 다시 작성됩니다.

디지털 서명/암호화/권한으로 보호된 메시지

주소 다시 쓰기는 대부분의 서명된 메시지나 암호화된 메시지 또는 권한이 보호된 메시지에 영향을 미치지 않아야 합니다. 주소 다시 쓰기로 인해 이러한 유형의 메시지 보안 상태가 무효화되거나 변경되는 경우 주소 다시 쓰기가 적용되지 않습니다.

다음 값은 정보가 메시지 서명, 암호화 또는 권한 보호의 일부분이 아니므로 다시 쓸 수 있습니다.

  • 메시지 봉투의 필드입니다.

  • 최상위 메시지 본문 헤더입니다.

다음 값은 정보가 메시지 서명, 암호화 또는 권한 보호의 일부분이므로 다시 쓰여지지 않습니다.

  • 서명할 수 있는 MIME 본문 부분 내에 있는 헤더 필드입니다.

  • MIME 콘텐츠 형식의 경계 문자열 매개 변수입니다.