Sun Java System Messaging Server 6 2005Q4 관리 설명서

암호화 및 인증서 기반 인증 구성

이 절에는 다음과 같은 하위 절이 포함됩니다.

Messaging Server는 클라이언트 및 서버의 암호화된 통신과 인증서 기반 인증을 위해 TLS(Transport Layer Security) 프로토콜(또는 SSL(Secure Sockets Layer) 프로토콜로 알려져 있음)을 사용합니다. Messaging Server는 SSL 버전 3.0 및 3.1을 지원합니다. TLS는 SSL과 완전히 호환되며 필요한 모든 SSL 기능을 포함합니다.

SSL에 대한 배경 정보는 Introduction to SSL(Managing Servers with iPlanet Console의 부록으로 제공됨)을 참조하십시오. SSL은 Introduction to Public-Key Cryptography(Managing Servers with iPlanet Console의 부록으로 제공됨)에 설명되어 있는 공개 키 암호화의 개념에 기초합니다.

Messaging Server와 클라이언트 간의 메일이나 Messaging Server와 다른 서버 간의 메일 전송이 암호화될 경우 통신에서 도청이 발생할 가능성이 거의 없습니다. 또한 연결하는 클라이언트가 인증될 경우 침입자가 클라이언트를 가장(스푸핑)할 가능성이 거의 없습니다.

SSL은 IMAP4, HTTP, POP3 및 SMTP의 응용 프로그램 계층 아래에 있는 프로토콜 계층의 기능을 수행합니다. SMTP 및 SMTP/SSL은 같은 포트를 사용하고 HTTP 및 HTTP/SSL에는 다른 포트가 필요하며 IMAP 및 IMAP/SSL과 POP 및 POP/SSL은 같은 포트나 다른 포트를 사용할 수 있습니다. 그림 19–1에 나온 것처럼 SSL은 보내는 메일과 받는 메일 모두에 대해 특정 메일 통신 단계에서 작동합니다.

그림 19–1 Messaging Server와의 암호화된 통신

SSL은 홉 간의 암호화를 제공하지만 메일은 각 중간 서버에서 암호화되지 않습니다.

주 –

보내는 메일에 대한 암호화를 사용하려면 maytls, musttls 등의 tls 채널 키워드를 포함하도록 채널 정의를 수정해야 합니다. 자세한 내용은 전송 계층 보안을 참조하십시오.

SSL 연결을 설정하는 과정에서 발생하는 추가 오버헤드가 서버의 성능에 부담을 줄 수 있다는 것에 주의합니다. 따라서 메시징 설치를 디자인하고 성능을 분석할 경우 서버 용량과 보안 요구 사항 간에 적절히 균형을 맞추는 것이 필요합니다.

주 –

모든 Sun Java System 서버가 SSL을 지원하며 콘솔을 통해 SSL을 사용 가능하게 하고 구성하기 위한 인터페이스가 대부분의 서버에서 거의 동일하기 때문에 이 절에 설명된 여러 작업은 Managing Servers with iPlanet Console의 SSL 장에 더 자세하게 설명되어 있습니다. 이 장에서는 이러한 작업에 대한 요약 정보만 제공합니다.

관리 콘솔을 통해 인증서 얻기

SSL을 암호화에 사용하는지 아니면 인증에 사용하는지 여부에 상관 없이 Messaging Server에 대한 서버 인증서를 얻어야 합니다. 인증서는 해당 서버를 클라이언트와 다른 서버에 대해 식별합니다. 관리 콘솔을 통해 인증서를 얻으려면 이 절의 단계를 수행합니다. 명령줄 모드에서 자체 서명된 인증서를 만들려면 자체 서명된 인증서 만들기를 참조하십시오.

내부 및 외부 모듈 관리

서버 인증서는 데이터를 암호화 및 해독하는 데 사용되는 숫자인 키 쌍의 소유권과 유효성을 설정합니다. 서버 인증서와 키 쌍은 서버의 신원을 나타내며 서버 내부이거나 외부의 이동식 하드웨어 카드(스마트 카드)가 될 수 있는 인증서 데이터베이스에 저장됩니다.

Sun Java System 서버는 PKCS(Public-Key Cryptography System) #11 API를 따르는 모듈을 사용하여 키 및 인증서 데이터베이스에 액세스합니다. 특정 하드웨어 장치의 PKCS #11 모듈은 일반적으로 해당 제공자로부터 얻을 수 있으며 Messaging Server에 설치한 후에만 Messaging Server에서 해당 장치를 사용할 수 있습니다. 미리 설치된 "Netscape Internal PKCS # 11 Module"은 서버 내부의 인증서 데이터베이스를 사용하는 단일 내부 소프트웨어 토큰을 지원합니다.

인증서 사용을 위해 서버를 설정하는 작업에는 인증서와 해당 키를 위한 데이터베이스를 만들고 PKCS #11 모듈을 설치하는 것이 포함됩니다. 외부 하드웨어 토큰을 사용하지 않을 경우 서버에서 내부 데이터베이스를 만들고 Messaging Server의 일부인 내부 기본 모듈을 사용합니다. 외부 토큰을 사용할 경우 하드웨어 스마트 카드 판독기를 연결하고 해당 PKCS #11 모듈을 설치합니다.

내부 및 외부 PKCS #11 모듈을 모두 콘솔을 통해 관리할 수 있습니다. PKCS #11 모듈을 설치하려면 다음을 수행합니다.

하드웨어 카드 판독기를 Messaging Server 호스트 시스템에 연결하고 드라이버를 설치합니다.
콘솔에서 PKCS #11 관리 인터페이스를 사용하여 설치된 드라이버를 위한 PKCS #11 모듈을 설치합니다.

보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

하드웨어 암호화 가속기 설치. 암호화를 위해 SSL을 사용할 경우 하드웨어 암호화 가속기를 설치하여 메일을 암호화 및 해독하는 서버의 성능을 향상시킬 수 있습니다. 일반적으로 암호화 가속기는 서버 시스템에 영구적으로 설치된 하드웨어 보드와 소프트웨어 드라이버로 구성됩니다. Messaging Server는 PKCS #11 API를 따르는 가속기 모듈을 지원합니다. (이러한 모듈은 기본적으로 고유한 키를 저장하지 않으며 이를 위한 내부 데이터베이스를 사용하는 하드웨어 토큰입니다.) 가속기를 설치하려면 우선 하드웨어와 드라이버를 제조업체에서 지정한 대로 설치한 다음 하드웨어 인증서 토큰과 마찬가지로 PKCS #11 모듈을 설치하여 설치를 완료합니다.

서버 인증서 요청

콘솔에서 서버를 열고 인증서 설정 마법사를 실행하여 서버 인증서를 요청합니다. 이 마법사는 콘솔 메뉴나 Messaging Server 암호화 탭에서 액세스할 수 있습니다. 이 마법사를 사용하여 다음 작업을 수행합니다.

단계

인증서 요청을 생성합니다.

인증서를 발급한 인증 기관(CA)에 전자 메일로 요청을 보냅니다.

CA로부터 전자 메일 응답이 도착하면 이를 텍스트 파일로 저장하고 인증서 설정 마법사를 사용하여 설치합니다.

보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

인증서 설치

설치는 요청 생성과 별개의 프로세스입니다. 인증서 요청에 대한 전자 메일 응답이 CA로부터 도착했으며 이를 텍스트 파일로 저장한 후에는 인증서 설정 마법사를 한 번 더 실행하여 다음과 같이 파일을 인증서로 설치합니다.

단계

이미 얻은 인증서를 설치하고 있다는 것을 지정합니다.

인증서의 텍스트를 필드에 붙여넣습니다(그렇게 하라는 메일이 나타났을 때).

인증서 별명을 server-cert에서 Server-Cert로 변경합니다.

인증서 별명을 변경하지 않으려면 configutil 매개 변수 encryption.rsa.nssslpersonalityssl을 설정하여 시스템에서 원하는 인증서 별명을 변경할 수 있습니다.

보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 )

주 –
이것은 또한 다음에 설명하는 CA 인증서를 설치할 때 따르는 프로세스입니다. 서버는 CA 인증서를 사용하여 클라이언트가 제공한 인증서를 신뢰할지 여부를 결정합니다.

신뢰할 수 있는 CA의 인증서 설치

또한 인증서 설정 마법사를 사용하여 인증 기관의 인증서를 설치할 수 있습니다. CA 인증서는 CA 자체의 신원을 검증합니다. 서버는 클라이언트 및 다른 서버를 인증하는 과정에서 이러한 CA 인증서를 사용합니다.

예를 들어, 비밀번호 기반 인증 외에 인증서 기반 클라이언트 인증이 가능하도록 설정한 경우(157페이지의 "인증 기반 로그인 설정" 참조) 클라이언트가 제공할 수 있는 인증서를 발급하는 신뢰할 수 있는 모든 CA의 CA 인증서를 설치해야 합니다. 이러한 CA는 조직 내부에 대한 것이거나 민간 또는 정부 기관이나 다른 회사 등 외부에 대한 것일 수 있습니다. (인증을 위한 CA 인증서 사용에 대한 자세한 내용은 Managing Servers with iPlanet Console에서 Introduction to Public-Key Cryptography를 참조하십시오.)

Messaging Server를 설치하면 여러 상용 CA에 대한 CA 인증서가 기본적으로 포함되어 있습니다. 다른 상용 CA를 추가해야 하거나 회사에서 내부 용도의 고유한 CA를 개발(Sun Java System Certificate Server 사용)하는 중이면 추가 CA 인증서를 얻어 설치해야 합니다.

주 –

Messaging Server에서 자동으로 제공되는 CA 인증서는 처음에 클라이언트 인증서에 대해 신뢰할 수 있는 것으로 표시되지 않습니다. 따라서 이러한 CA에 의해 발급된 클라이언트 인증서를 신뢰하려면 트러스트 설정을 편집해야 합니다. 자세한 지침은 153페이지의 "인증 및 신뢰할 수 있는 CA 관리"를 참조하십시오.

새 CA 인증서를 요청하여 설치하려면 다음을 수행합니다.

새 CA 인증서 요청 및 설치 방법

단계

인증 기관에 문의하여(대부분의 웹 또는 전자 메일을 통해) 해당 CA 인증서를 다운로드합니다.

받은 인증서의 텍스트를 텍스트 파일로 저장합니다.

앞의 절에 설명된 대로 인증서 설정 마법사를 사용하여 인증서를 설치합니다.

보다 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

인증서 및 신뢰할 수 있는 CA 관리

서버는 신뢰할 수 있는 CA의 여러 인증서를 클라이언트 인증에 사용할 수 있습니다.

콘솔에서 서버를 열고 콘솔 메뉴에서 인증서 관리 명령을 선택하여 Messaging Server에 설치된 모든 인증서를 확인하거나, 해당 트러스트 설정을 편집하거나, 인증서 자체를 삭제할 수 있습니다. 자세한 지침은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

비밀번호 파일 만들기

모든 Sun Java System 서버에서 인증서 설정 마법사를 사용하여 인증서를 요청하면 마법사는 내부 모듈의 데이터베이스나 스마트 카드의 외부 데이터베이스에 저장되는 키 쌍을 만듭니다. 그런 다음 이 마법사는 개인 키를 암호화하는 데 사용되는 비밀번호를 묻는 메시지를 표시합니다. 나중에 이와 동일한 비밀번호를 통해서만 키를 해독할 수 있습니다. 이 마법사는 비밀번호를 보유하거나 임의의 위치에 저장하지 않습니다.

SSL이 사용 가능하게 되는 대부분의 Sun Java System 서버에서는 키 쌍을 해독하는 데 필요한 비밀번호를 제공하라는 메시지가 시작 시에 관리자에게 표시됩니다. 그러나 Messaging Server에서는 비밀번호를 여러 번 입력(최소한 세 개의 서버 프로세스에 필요함)하는 불편함을 없애고 무인 서버의 다시 시작을 용이하게 만들기 위해 비밀번호를 비밀번호 파일에서 읽습니다.

비밀번호 파일의 이름은 sslpassword.conf이며 msg_svr_base/config/ 디렉토리에 위치합니다. 이 파일의 항목은 다음 형식을 갖는 개별 행입니다.

moduleName:password

여기에서 moduleName은 사용할 내부 또는 외부 PKCS #11 모듈의 이름이며 password는 모듈의 키 쌍을 해독하는 비밀번호입니다. 비밀번호는 일반(암호화되지 않은) 텍스트로 저장됩니다.

Messaging Server는 내부 모듈 및 기본 비밀번호를 위한 다음과 같은 단일 항목을 가지는 기본 버전의 비밀번호 파일을 제공합니다.

Internal (Software) Token:netscape!

내부 인증서를 설치할 때 기본값이 아닌 비밀번호를 지정할 경우 비밀번호 파일의 위 행을 편집하여 지정된 비밀번호를 반영해야 합니다. 외부 모듈을 설치할 경우 이에 대해 지정한 모듈 이름과 비밀번호를 포함하는 새 행을 파일에 추가해야 합니다.

주의 –

서버 시작 시에 모듈 비밀번호를 묻는 메시지가 관리자에게 표시되지 않으므로 서버에 대한 관리자 액세스 제어와 서버 호스트 시스템 및 해당 백업의 물리적 보안을 적절하게 하는 것이 특히 중요합니다.

자체 서명된 인증서 만들기

명령줄모드에서자체서명된인증서를만들려면이절의지침을따릅니다인증서 마법사를 사용하여 인증서를 만들려면 관리 콘솔을 통해 인증서 얻기 를 참조하십시오.

자체 서명된 인증서 만들기

단계

수퍼유저로 로그인하거나 수퍼유저(root)가 됩니다.

/opt/SUNWmsgsr/config/sslpassword에서 certutil에 대한 인증서 데이터베이스 비밀번호를 지정합니다. 예를 들면 다음과 같습니다.
# echo "password" > /opt/SUNWmsgsr/config/sslpassword
여기서 password는 해당 비밀번호입니다.

sbin 디렉토리로 이동하여 인증서 데이터베이스(cert8.db) 및 키 데이터베이스(key3.db)를 생성합니다. 예를 들면 다음과 같습니다.
# cd /opt/SUNWmsgsr/sbin # ./certutil -N -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword

자동 서명된 기본 루트 인증 기관 인증서를 생성합니다. 예:

# ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
-s "CN=My Sample Root CA, O=sesta.com" -m 25000
-o /opt/SUNWmsgsr/config/SampleRootCA.crt
-d /opt/SUNWmsgsr/config
-f /opt/SUNWmsgsr/config/sslpassword   -z /etc/passwd

호스트에 대한 인증서를 생성합니다. 예를 들면 다음과 같습니다.

../certutil -S -n Server-Cert -c SampleRootCA -t "u,u,u"
-s "CN=hostname.sesta.com, o=sesta.com" -m 25001
-o /opt/SUNWmsgsr/config/SampleSSLServer.crt
-d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword
-z /etc/passwd

여기서 hostname.sesta.com은 서버 호스트 이름입니다.

인증서의 유효성을 검사합니다. 예를 들면 다음과 같습니다.

# ./certutil -V -u V -n  SampleRootCA -d /opt/SUNWmsgsr/config
# ./certutil -V -u V -n  Server-Cert -d /opt/SUNWmsgsr/config

인증서를 나열합니다. 예를 들면 다음과 같습니다.

# ./certutil -L -d /opt/SUNWmsgsr/config
# ./certutil -L -n Server-Cert -d /opt/SUNWmsgsr/config

modutil을 사용하여 사용 가능한 보안 모듈(secmod.db)을 나열합니다. 예를 들면 다음과 같습니다.
# ./modutil -list -dbdir /opt/SUNWmsgsr/config

예에 나온 것처럼 인증서 데이터베이스 파일의 소유자를 메일 서버 사용자 및 그룹으로 변경합니다.
chown mailsrv:mail /opt/SUNWmsgsr/config/cert8.db chown mailsrv:mail /opt/SUNWmsgsr/config/key3.db

메시징 서비스를 다시 시작하여 SSL을 활성화합니다.

주 –
이전에는 인증서와 키 파일이 항상 Messaging Server 구성 디렉토리에 있었습니다. 이제는 이러한 파일의 위치를 local.ssldbpath(인증서 및 키 파일의 위치 지정) 및 local.ssldbprefix(인증서 및 키 파일의 접두어 지정)를 사용하여 지정하는 일이 )

SSL 사용 및 암호문 선택

콘솔을 사용하여 SSL을 사용 가능하게 하고 Messaging Server가 클라이언트와의 암호화된 통신에 사용할 수 있는 암호화 암호문 집합을 선택할 수 있습니다.

암호문 정보

암호문은 암호화 프로세스에서 데이터를 암호화 및 해독하는 데 사용되는 알고리즘입니다. 일부 암호문은 다른 암호문보다 강력한데 이는 이러한 암호문으로 스크램블된 메일을 권한 없는 사용자가 해독하는 것이 더 어렵다는 것을 의미합니다.

암호문은 키(긴 번호)를 데이터에 적용하는 방법으로 데이터에서 작동합니다. 일반적으로 암호문이 암호화 도중에 사용하는 키가 더 길수록 적절한 암호화 키 없이 데이터를 해독하는 것이 어려워집니다.

클라이언트는 Messaging Server와의 SSL 연결을 시작할 때 암호화에 사용할 선호되는 암호문과 키 길이를 서버에 알려줍니다. 모든 암호화된 통신에서 클라이언트와 서버는 동일한 암호문을 사용해야 합니다. 일반적으로 다양한 암호문 및 키 조합이 사용되기 때문에 서버는 암호화를 유연하게 지원해야 합니다. Messaging Server는 암호문 및 키 길이 조합을 최대 6개까지 지원할 수 있습니다.

표 19–2에는 SSL 3.0과 함께 사용하는 Messaging Server에서 지원하는 암호문을 나열합니다. 이 표에 요약된 정보의 자세한 내용은 Managing Servers with iPlanet Console의 Introduction to SSL 절에서 확인할 수 있습니다.

표 19–2 Messaging Server의 SSL 암호문


암호문	설명
128비트 암호화 및 MD5 메일 인증을 사용하는 RC4	가장 빠른 암호화 암호문(RSA에 의한)이며 강도가 매우 높은 암호문 및 암호화 키의 조합입니다.
168비트 암호화 및 SHA 메일 인증을 사용하는 Triple DES	더 느린 암호화 암호문(미국 정보 표준)이지만 강도가 가장 높은 암호문 및 암호화 키의 조합입니다.
56비트 암호화 및 SHA 메일 인증을 사용하는 DES	더 느린 암호화 암호문(미국 정보 표준)이며 강도가 보통인 암호문 및 암호화 키의 조합입니다.
40비트 암호화 및 MD5 메일 인증을 사용하는 RC4	가장 빠른 암호화 암호문(RSA에 의한)이며 강도가 낮은 암호문 및 암호화 키의 조합입니다.
40비트 암호화 및 MD5 메일 인증을 사용하는 RC2	더 느린 암호화 암호문(RSA에 의한)이며 강도가 낮은 암호문 및 암호화 키의 조합입니다.
암호화 없음, MD5 메일 인증만 사용	암호화가 없으며 메일 다이제스트만 인증에 사용됩니다.

특정 암호문을 사용하지 않을 중요한 이유가 없을 경우 모든 암호문을 지원해야 합니다. 그러나 일부 국가에서는 수출법에 따라 특정 암호화 암호문의 사용이 제한된다는 것에 주의합니다. 또한 미국 수출 제한법이 완화되기 전에 만들어진 일부 클라이언트 소프트웨어는 더 높은 강도의 암호화를 사용할 수 없습니다. 40비트 암호문이 우발적인 도청을 방지할 수 있지만 보안되지는 않으므로 적극적인 공격을 차단하지 않는다는 것에 주의합니다.

SSL을 사용 가능하게 하고 암호화 암호문을 선택하려면 다음 명령줄 단계를 따릅니다.

SSL을 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o nsserversecurity -v [ on | off ]

RSA 암호문을 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o encryption.rsa.nssslactivation -v [ on | off ]

토큰을 지정하려면 다음을 수행합니다.

configutil -o encryption.rsa.nsssltoken -v tokenname

인증서를 지정하려면 다음을 수행합니다.

configutil -o encryption.rsa.nssslpersonalityssl -v certname

RSA 암호문을 사용 가능하게 할 경우 또한 토큰과 인증서를 지정해야 한다는 것에 주의합니다.

암호문 기본 설정을 선택하려면 다음을 수행합니다.

configutil -o encryption.nsssl3ciphers -v cipherlist

여기에서 cipherlist는 쉼표로 구분된 암호문 목록입니다.

주 –

보내는 메일에 대해 SSL 암호화를 사용하려면 채널 정의를 수정하여 maytls, musttls 등의 tls 채널 키워드를 포함해야 합니다. 자세한 내용은 전송 계층 보안을 참조하십시오.

인증서 기반 로그인 설정

비밀번호 기반 인증 외에도 Sun Java System 서버는 디지털 인증서 검사를 통한 사용자 인증을 지원합니다. 인증서 기반 인증에서 클라이언트는 서버와의 SSL 세션을 설정하고 사용자의 인증서를 서버로 제출합니다. 그런 다음 서버는 제출된 인증서가 진짜인지 여부를 평가합니다. 인증서가 검증될 경우 사용자는 인증된 것으로 간주됩니다.

인증서 기반 로그인을 사용하도록 Messaging Server를 설정하려면 다음을 수행합니다.

인증서 기반 로그인 설정

단계

서버의 서버 인증서를 얻습니다. 자세한 내용은 관리 콘솔을 통해 인증서 얻기 를 참조하십시오.

인증서 설정 마법사를 실행하여 서버가 인증할 사용자에게 인증서를 발급하는 신뢰할 수 있는 모든 인증 기관의 인증서를 설치합니다. 자세한 내용은 신뢰할 수 있는 CA의 인증서 설치을 참조하십시오.

서버의 데이터베이스에 최소한 하나 이상의 신뢰할 수 있는 CA가 있을 경우 서버는 각 연결 클라이언트로부터 클라이언트 인증서를 요청한다는 것에 주의합니다.

SSL을 설정합니다. 자세한 내용은 SSL 사용 및 암호문 선택을 참조하십시오.

(선택 사항) 제출된 인증서의 정보에 기초하여 서버가 LDAP 사용자 디렉토리를 적절하게 검색하도록 서버의 certmap.conf 파일을 편집합니다.

사용자의 인증서에 있는 전자 메일 주소가 사용자의 디렉토리 항목에 있는 전자 메일 주소와 일치하며 검색을 최적화하거나 사용자 항목의 인증서에 대해 제출된 인증서를 검증할 필요가 없을 경우에는 certmap.conf 파일을 편집할 필요가 없습니다.

certmap.conf의 형식과 변경할 수 있는 사항에 대한 자세한 내용은 Managing Servers with iPlanet Console에서 SSL 장을 참조하십시오.

이러한 단계를 수행하고 나면 사용자가 IMAP 또는 HTTP에 로그인할 수 있도록 클라이언트가 SSL 세션을 설정할 때 Messaging Server는 클라이언트로부터 사용자의 인증서를 요청합니다. 클라이언트에 의해 제출된 인증서가 서버에서 신뢰할 수 있는 것으로 설정한 CA가 발급했으며 인증서의 아이디가 사용자 디렉토리의 항목과 일치할 경우 사용자가 인증되며 액세스가 허가됩니다(해당 사용자를 제어하는 액세스 제어 규칙에 따라).

인증서 기반 로그인을 사용 가능하게 하기 위해 비밀번호 기반 로그인을 허용하지 않을 필요는 없습니다. 비밀번호 기반 로그인이 허용되는 기본 상태에서 이 절에 설명된 작업을 수행할 경우 비밀번호 기반 및 인증서 기반 로그인이 모두 지원됩니다. 이 경우 클라이언트가 SSL 세션을 설정하고 인증서를 제공할 경우 인증서 기반 로그인이 사용됩니다. 클라이언트가 SSL을 사용하지 않거나 인증서를 제공하지 않을 경우 서버는 비밀번호를 요청합니다.

SMTP 프록시를 사용하여 SSL 성능을 최적화하는 방법

SMTP 프록시는 SMTP 프로토콜에 추가 대기 시간을 야기하므로 대부분의 사이트는 SMTP 프록시를 사용해서는 안 됩니다. 그러나 SMTP 연결을 보호하기 위해 SSL에 많이 의존하는 대규모 사이트는 SSL 및 프록시 외에는 일체 수행하지 않는 서버에서 모든 프로토콜에 대해 모든 SSL 작업을 수행하여 SSL 가속기 하드웨어에 대한 투자를 극대화하길 원할 수 있습니다. SMTP 프록시를 사용하면 메일 대기열을 별개의 MTA 시스템에 두면서 SSL을 프런트엔드 프록시 서버에서 처리할 수 있습니다. 이러한 방법으로 각 작업에 대해 최적화된 하드웨어를 별도로 구성 및 구입할 수 있습니다.

SMTP 프록시를 설치하는 방법에 대한 지침은 POP before SMTP 사용를 참조하십시오.