test

Sun Java System Messaging Server 6.3 관리 설명서

5장 POP, IMAP 및 HTTP 서비스 구성

Messaging Server는 메일함에 대한 클라이언트 액세스를 위해 POP3(Post Office Protocol 3), IMAP4(Internet Mail Access Protocol 4) 및 HTTP(HyperText Transfer Protocol)를 지원합니다. IMAP 및 POP는 모두 인터넷 표준 메일함 프로토콜입니다. 웹 사용 가능 전자 메일 프로그램인 Messenger Express를 사용하면 최종 사용자는 HTTP를 사용하는 인터넷에 연결된 컴퓨터 시스템에서 실행 중인 브라우저를 통해 자신의 메일함에 액세스할 수 있습니다.

이 장에서는 명령줄 유틸리티를 사용하여 이러한 서비스를 하나 이상 지원하도록 서버를 구성하는 방법에 대해 설명합니다.

SMTP(Simple Mail Transfer Protocol) 서비스 구성에 대한 자세한 내용은 10 장, MTA 서비스 및 구성 정보을 참조하십시오.

이 장은 다음 내용으로 구성되어 있습니다.

5.1 일반 구성

Messaging Server POP, IMAP 및 HTTP 서비스의 일반 기능을 구성하는 작업에는 서비스를 활성화/비활성화하고 포트 번호를 할당하며 선택적으로 연결 클라이언트에 보내진 서비스 배너를 수정하는 것이 포함됩니다. 이 절에서는 이에 대한 배경 정보를 제공합니다. 이러한 설정을 위해 따라야 하는 단계는 5.5 POP 서비스 구성, 5.6 IMAP 서비스 구성 및 5.7 HTTP 서비스 구성을 참조하십시오. 이 절은 다음과 같은 하위 절로 구성되어 있습니다.

5.1.1 서비스 활성화/비활성화

Messaging Server의 특정 인스턴스가 POP, IMAP 또는 HTTP 서비스를 활성화할지 여부를 제어할 수 있습니다. 이것은 서비스를 시작 및 중지하는 것과 다릅니다( 4.4 서비스 시작 및 중지 참조). POP, IMAP 또는 HTTP 서비스가 작동하려면 해당 서비스를 사용 가능하게 한 다음 시작해야 합니다.

서비스를 사용 가능하게 하는 것은 서비스를 시작 또는 중지하는 것보다 “전역적인” 과정입니다. 예를 들어, 사용 가능 설정은 시스템 재부트 후에도 계속 유지되지만 이전에 “중지된” 서비스는 재부트 후에 다시 시작해야 합니다.

사용할 계획이 없는 서비스를 사용 가능하게 할 필요가 없습니다. 예를 들어, Messaging Server 인스턴스를 단지 MTA(mail transfer agent)로 사용할 경우 POP, IMAP 및 HTTP를 사용 불가능하게 해야 합니다. 이 인스턴스가 POP 서비스에만 사용될 경우 IMAP 및 HTTP를 사용 불가능하게 하고웹 기반 전자 메일에만 사용될 경우 POP 및 IMAP를 사용 불가능하게 해야 합니다.

서버 수준에서 서비스를 사용 가능/불가능하게 할 수 있습니다. 이 프로세스는 이 장과 4.4.2.1 시작할 서비스 지정에 설명되어 있습니다. 또한 LDAP 속성 mailAllowedServiceAccess를 설정하여 사용자 수준에서 서비스를 활성화/비활성화할 수도 있습니다.

5.1.2 포트 번호 지정

각 서비스에 대해 서버가 서비스 연결에 사용할 포트 번호를 지정할 수 있습니다.

경우에 따라서는 기본값이 아닌 포트 번호를 지정해야 할 수 있습니다. 예를 들어 두 개 이상의 서버 인스턴스가 단일 호스트 시스템에 있거나 IMAP 서버 및 Messaging Multiplexor 서버와 동일한 호스트 시스템을 사용하는 경우 등입니다. Multiplexor에 대한 자세한 내용은 7 장, 멀티플렉서 서비스 구성 및 관리을 참조하십시오.

포트를 지정할 때는 다음 사항을 유의하십시오.

5.1.3 암호화된 통신을 위한 포트

Messaging Server는 SSL(Secure Sockets Layer) 프로토콜을 사용하여 IMAP, POP 및 HTTP 클라이언트와의 암호화된 통신을 지원합니다. Messaging Server의 SSL 지원에 대한 일반 정보는 23.5 암호화 및 인증서 기반 인증 구성 을 참조하십시오.

5.1.3.1 SSL을 통한 IMAP

SSL을 통한 IMAP에 대해 기본(권장) 포트 번호(993)를 그대로 사용하거나 별개의 포트를 지정할 수 있습니다.

대부분의 현재 IMAP 클라이언트에 별개의 포트가 필요하므로 Messaging Server는 IMAP 및 SSL을 통한 IMAP에 대해 별개의 포트를 사용하는 옵션을 제공합니다. IMAP 및 SSL을 통한 IMAP 모두에 동일한 포트를 사용하는 통신은 새로운 표준으로 등장하고 있습니다. Messaging Server에 설치된 SSL 인증서가 있을 경우( 23.5.1 인증서 얻기 참조) SSL을 통한 동일 포트 IMAP를 지원할 수 있습니다.

5.1.3.2 SSL을 통한 POP

POP에 대한 기본적인 별도 SSL 포트는 995입니다. “STLS” 명령을 사용하여 일반적인 POP 포트를 통해 SSL을 초기화할 수도 있습니다( 5.5 POP 서비스 구성 참조).

5.1.3.3 SSL을 통한 HTTP

SSL을 통한 HTTP에 대해 기본 포트 번호(443)를 그대로 사용하거나 HTTP에 대해 다른 포트를 지정할 수 있습니다.

5.1.4 서비스 배너

클라이언트가 POP 또는 IMAP 포트에 처음 연결되면 서버는 식별 텍스트 문자열 클라이 언트에게 보냅니다. 일반적으로 클라이언트의 사용자에게 표시되지 않는 이 서비스 배너는 서버를 Sun Java System Messaging Server로 식별하고 서버의 버전 번호를 제공합니다. 이 배너는 대부분 클라이언트 디버깅 또는 문제 해결 목적에 사용됩니다.

연결 클라이언트에 다른 메시지를 보내려는 경우 POP 또는 IMAP 서비스의 기본 배너를 바꿀 수 있습니다.

configutil 유틸리티(service.imap.banner, service.pop.banner)를 사용하여 서비스 배너를 설정합니다. configutil에 대한 자세한 구문 정보는 Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

5.2 로그인 요구 사항

메일을 검색하기 위해 POP, IMAP 또는 HTTP 서비스에 로그인하는 사용자를 허용하는 방법을 제어할 수 있습니다. 모든 서비스에 대해 비밀번호 기반 로그인을 허용하거나 IMAP 또는 HTTP 서비스에 대해 인증서 기반 로그인을 허용할 수 있습니다. 이 절에서는 이에 대한 배경 정보를 제공합니다. 이러한 설정을 위해 따라야 하는 단계는 5.5 POP 서비스 구성, 5.6 IMAP 서비스 구성 또는 5.7 HTTP 서비스 구성을 참조하십시오. 또한 POP 로그인에 대한 유효한 로그인 구분자를 지정할 수도 있습니다. 이 절은 다음과 같은 하위 절로 구성되어 있습니다.

ProcedurePOP 클라이언트에 대한 로그인 구분자 설정

일부 메일 클라이언트는 @을 로그인 구분자(즉, uid@domain과 같은 주소의 @)로 허용하지 않습니다. 이러한 클라이언트의 예로는 Netscape Messenger 4.76, Netscape Messenger 6.0, Windows 2000의 Microsoft Outlook Express 등을 들 수 있습니다. 이에 대한 해결 방법은 다음과 같습니다.

  1. 다음 명령으로 +를 유효한 구분자로 만듭니다.

    configutil -o service.loginseparator -v "@+"

  2. @이 아니라 +를 로그인 구분자로 사용하여 로그인해야 한다는 것을 POP 클라이언트 사용자에게 알립니다.

5.2.1 도메인 이름을 사용하지 않고 로그인 허용

일반적인 로그인의 경우 사용자는 사용자 아이디를 입력하고 구분자와 도메인 이름을 입력한 다음 비밀번호를 입력합니다. 그러나 설치 도중에 지정하는 기본 도메인의 사용자는 도메인 이름이나 구분자를 입력하지 않고 로그인할 수 있습니다.

사용자 아이디만 사용하여(즉, 도메인 이름과 구분자를 사용하지 않고) 다른 도메인의 사용자가 로그인할 수 있게 하려면 sasl.default.ldap.searchfordomain을 0으로 설정합니다. 사용자 아이디는 전체 디렉토리 트리에서 고유해야 한다는 것에 주의하십시오. 사용자 아이디가 고유하지 않을 경우 도메인 이름 없이 로그인할 수 없습니다.

로그인하기 위해 사용자가 입력해야 하는 속성을 수정할 수 있습니다. 예를 들어, 사용자가 전화 번호(telephoneNumber) 또는 직원 번호(employeeID)를 사용하여 로그인할 수 있게 하려면 configutil 매개 변수 sasl.default.ldap.searchfilter에서 정의하는 LDAP 검색을 변경합니다. 이 매개 변수는 inetDomainSearchFilter 도메인별 속성의 전역 기본 설정이며 동일한 구문을 사용합니다.

이 매개 변수에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

5.2.2 비밀번호 기반 로그인

일반적인 메시징 설치에서는 사용자가 자신의 POP, IMAP 또는 HTTP 메일 클라이언트에 비밀번호를 입력함으로써 메일함에 액세스합니다. 클라이언트가 비밀번호를 서버에 보내면 서버는 이를 사용하여 사용자를 인증합니다. 사용자가 인증되면 서버는 액세스 제어 규칙에 기초하여 사용자에게 해당 서버에 저장된 특정 메일함에 대한 액세스를 허용할 것인지 결정합니다.

비밀번호 로그인을 허용할 경우 사용자는 비밀번호를 입력하여 POP, IMAP 또는 HTTP에 액세스할 수 있습니다. 비밀번호 기반 또는 SSL 기반 로그인은 POP 서비스를 위한 유일한 인증 방법입니다. 비밀번호는 LDAP 디렉토리에 저장됩니다. 디렉토리 정책에 따라 적용되는 비밀번호 정책(예: 최소 길이)이 결정됩니다.

IMAP 또는 HTTP 서비스에 대한 비밀번호 로그인을 허용하지 않을 경우 비밀번호 기반 인증이 허용되지 않습니다. 이 경우 사용자는 다음 절에 설명된 대로 인증서 기반 로그인을 사용해야 합니다.

IMAP 및 HTTP 서비스에 대한 비밀번호 전송의 보안을 향상시키려면 비밀번호를 서버로 보내기 전에 암호화하도록 요구할 수 있습니다. 이렇게 하려면 로그인에 대한 최소 암호화 길이 요구 사항을 선택합니다.

서버에서 지원하는 최대값보다 큰 키 길이로 암호화하도록 클라이언트가 구성되었거나 클라이언트가 지원하는 최대값보다 큰 키 길이로 암호화하도록 서버가 구성된 경우 비밀번호 기반 로그인을 수행할 수 없습니다. 다양한 암호화 및 키 길이를 지원하도록 서버를 설정하는 방법에 대한 자세한 내용은 23.5.2 SSL 사용 및 암호문 선택을 참조하십시오.

5.2.3 인증서 기반 로그인

비밀번호 기반 인증 외에도 Sun Java System 서버는 디지털 인증서 검사를 통한 사용자 인증을 지원합니다. 이 경우, 클라이언트는 서버와의 SSL 세션을 설정할 때 비밀번호를 제공하는 대신 사용자의 인증서를 제공합니다. 인증서가 검증될 경우 사용자는 인증된 것으로 간주됩니다.

IMAP 또는 HTTP 서비스에 대한 인증서 기반 사용자 로그인을 허용하도록 Messaging Server를 설정하는 방법에 대한 자세한 내용은 23.5.3 인증서 기반 로그인 설정을 참조하십시오.

인증서 기반 로그인을 설정하는 데 필요한 작업을 수행한 경우 비밀번호 기반 로그인 및 인증서 기반 로그인이 모두 지원됩니다. 그런 다음 클라이언트가 SSL 세션을 설정하고 인증서를 제공할 경우 인증서 기반 로그인이 사용됩니다. 클라이언트는 SSL을 사용하지 않으며 클라이언트 인증서를 제공하지 않을 경우에는 대신 비밀번호를 보냅니다.

5.3 성능 매개 변수

Messaging Server의 POP, IMAP 및 HTTP 서비스에 대한 몇 가지 기본 성능 매개 변수를 설정할 수 있습니다. 하드웨어 용량과 사용자 기반에 따라 이러한 매개 변수를 조정하여 최대한의 서비스 효율성을 실현할 수 있습니다. 이 절에서는 이에 대한 배경 정보를 제공합니다. 이러한 설정을 위해 따라야 하는 단계는 5.5 POP 서비스 구성, 5.6 IMAP 서비스 구성 또는 5.7 HTTP 서비스 구성을 참조하십시오. 이 절은 다음과 같은 하위 절로 구성되어 있습니다.

5.3.1 프로세스 수

Messaging Server는 여러 실행 프로세스 간에 작업을 분할할 수 있으며 이렇게 하면 경우에 따라 효율성이 향상될 수 있습니다. 이 기능은 특히 서버 프로세스 수를 조정했을 때 하드웨어 프로세서 간에 여러 작업을 더 효율적으로 분산시킬 수 있는 다중 프로세스 서버 시스템에서 유용합니다.

그러나 여러 프로세스 간에 작업을 할당하고 특정 프로세스에서 다른 프로세스로 전환하는 것에는 성능 오버헤드가 존재합니다. 여러 프로세스를 사용하는 자체의 이점은 새 프로세스를 추가할수록 줄어듭니다. 대부분의 구성에 적용되는 간단한 경험상의 규칙은 서버 시스템의 하드웨어 프로세서당 프로세스를 하나씩 가지는 것입니다(최대한 네 개까지 가능). 실제의 최적 구성이 이와 다를 수 있으므로 이 경험상의 규칙을 단순히 고유한 분석을 위한 지침으로 활용해야 할 것입니다.

주: 일부 플랫폼에서는 성능에 영향을 줄 수 있는 플랫폼 특정의 일정한 프로세스별 제한(예: 최대 파일 설명자 수)을 극복하기 위해 프로세스 수를 늘릴 수 있습니다.

각 POP, IMAP 또는 HTTP 서비스에 대한 기본 프로세스 수는 1입니다.

5.3.2 프로세스당 연결 수

POP, IMAP 또는 HTTP 서비스가 유지 관리할 수 있는 동시 클라이언트 연결이 많아질수록 클라이언트에게 더 유리합니다. 사용할 수 있는 연결이 없기 때문에 서비스가 거부될 경우 클라이언트는 다른 클라이언트가 연결을 끊을 때까지 기다려야 합니다.

반면, 열려 있는 각 연결은 메모리 자원을 소비하며 서버 시스템의 입출력 하위 시스템에 대한 요청을 하기 때문에 서버가 지원하리라 예상할 수 있는 동시 세션 수에는 실제적인 제한이 있습니다. 서버 메모리나 입출력 용량을 증가시켜 이러한 제한을 늘릴 수도 있습니다.

IMAP, HTTP 및 POP는 이 점에 있어서 요구 사항이 다릅니다.

주 –

HTTP 세션 보안에 대한 자세한 내용은 23.2 HTTP 보안 정보를 참조하십시오.

따라서 특정 시점의 특정 사용자 요구에 대해 Messaging Server는 POP 연결보다 더 많은 열려 있는 IMAP 및 HTTP 연결을 지원할 수 있습니다.

IMAP의 기본값은 4000이고 HTTP의 기본값은 프로세스당 6000개의 연결이며 POP의 기본값은 600입니다. 이러한 값은 일반적으로 구성된 서버 시스템이 처리할 수 있는 대략적으로 동일한 요구를 나타냅니다. 최적 구성이 이와 다를 수 있으므로 이러한 기본값을 단순히 일반적인 지침으로 사용해야 합니다.

일반적으로 활성 POP 연결은 활성 IMAP 연결보다 서버 리소스와 대역폭이 훨씬 더 많이 요구됩니다. 이는 IMAP 연결이 대부분의 시간에 유휴 상태인 것과 달리 POP 연결은 지속적으로 메시지를 다운로드하기 때문입니다. 따라서 POP에 대해 더 적은 수의 세션을 유지하는 것이 적합합니다. 반대로 POP 연결은 전자 메일을 다운로드하는 동안에만 지속되므로 활성 POP 사용자는 짧은 시간 동안만 연결되지만 IMAP 연결은 계속되는 메일 검사에서 연결된 상태로 유지됩니다.

5.3.3 프로세스당 스레드 수

여러 프로세스를 지원하는 것 외에도 Messaging Server는 여러 스레드 간에 작업을 분할하여 성능을 더욱 향상시킵니다. 서버의 스레드 사용은 실행 효율성을 크게 향상시키는데 이는 진행 중인 명령이 다른 명령의 실행을 저해하지 않기 때문입니다. 실행하는 동안에 필요에 따라 스레드는 설정된 최대 개수까지 작성 및 삭제됩니다.

동시에 실행되는 스레드가 많다는 것은 더 많은 클라이언트 요청을 지연 없이 처리할 수 있으며 이에 따라 더 많은 수의 클라이언트에게 신속하게 서비스할 수 있다는 것을 의미합니다. 그러나 스레드 간의 디스패칭으로 인해 성능 오버헤드가 발생하므로 서버가 사용할 수 있는 스레드 수에는 실제적인 제한이 존재합니다.

POP, IMAP 및 HTTP의 경우 기본 최대값은 프로세스당 250개의 스레드입니다. IMAP 및 HTTP의 기본 연결이 POP보다 많다는 사실에도 불구하고 이러한 기본값은 동일합니다. 수는 적지만 사용량이 많은 POP 연결과 동일한 최대 스레드 수를 사용하여 POP 연결보다 많은 수의 IMAP 및 HTTP 연결을 효율적으로 처리할 수 있는 것으로 알려져 있습니다. 실제의 최적 구성이 이와 다를 수 있지만 이러한 기본값으로 충분하기 때문에 값을 늘릴 필요는 없을 것입니다. 즉, 대부분의 설치에서 이러한 기본값은 적절한 성능을 제공합니다.

5.3.4 유휴 연결 해제

응답하지 않는 클라이언트의 연결에 사용된 시스템 자원을 재이용하기 위해 IMAP4, POP3 및 HTTP 프로토콜은 일정 시간 동안 유휴 상태였던 연결을 일방적으로 해제할 수 있는 기능을 서버에 제공합니다.

각 프로토콜 사양에서는 서버가 최소한의 시간 동안 유휴 연결을 열어두어야 합니다. 기본 시간은 POP는 10분, IMAP는 30분, HTTP는 3분입니다. 유휴 시간을 기본값보다 큰 값으로 늘릴 수 있지만 줄일 수는 없습니다.

POP 또는 IMAP 연결이 해제될 경우 새 연결을 설정하기 위해 사용자는 재인증되어야 합니다. 이와 달리 HTTP 연결이 해제될 경우 HTTP 세션이 계속 열려 있으므로 사용자를 재인증할 필요가 없습니다. HTTP 세션 보안에 대한 자세한 내용은 23.2 HTTP 보안 정보를 참조하십시오.

유휴 POP 연결은 일반적으로 클라이언트를 응답하지 않게 만드는 일부 문제(예: 충돌 또는 중지)로 인해 발생합니다. 반면, 유휴 IMAP 연결은 정상적인 상태입니다. IMAP 사용자가 일방적으로 연결이 끊기는 것을 방지하기 위해 IMAP 클라이언트는 일반적으로 30초 미만의 일정한 간격으로 IMAP 서버에 명령을 보냅니다.

5.3.5 HTTP 클라이언트 로그아웃

HTTP 세션은 여러 연결에서 지속될 수 있습니다. 연결이 해제될 때 HTTP 클라이언트는 로그아웃되지 않습니다. 그러나 지정된 기간(기본적으로 2시간) 동안 HTTP 세션이 유휴 상태이면 서버는 자동으로 HTTP 세션을 해제하고 클라이언트는 로그아웃됩니다. 세션이 해제되면 클라이언트의 세션 아이디가 더 이상 유효하지 않으므로 다른 세션을 설정하기 위해 클라이언트는 재인증되어야 합니다. HTTP 보안 및 세션 아이디에 대한 자세한 내용은 23.2 HTTP 보안 정보를 참조하십시오.

5.4 클라이언트 액세스 제어

Messaging Server에는 POP, IMAP 또는 HTTP 메시징 서비스와 SMTP에 대한 액세스를 어떤 클라이언트가 얻을 수 있는지 결정하는 액세스 제어 기능이 포함되어 있습니다. 다양한 기준에 기초하여 클라이언트에 대한 액세스를 허용 또는 거부하는 유연한 액세스 필터를 만들 수 있습니다.

클라이언트 액세스 제어는 Messaging Server의 중요한 보안 기능입니다. 클라이언트 액세스 제어 필터 작성에 대한 자세한 내용과 그 사용 예는 23.7 POP, IMAP 및 HTTP 서비스에 대한 클라이언트 액세스 구성 및 23.9 SMTP 서비스에 대한 클라이언트 액세스 구성을 참조하십시오.

5.5 POP 서비스 구성

configutil 명령을 사용하여 Messaging Server POP 서비스의 기본 구성을 수행할 수 있습니다. 이 절에서는 보다 일반적인 몇 가지 POP 서비스 옵션이 제공됩니다. 전체 목록은 Sun Java System Messaging Server 6.3 Administration Reference의 configutil Parameters에서 확인할 수 있습니다.

주 –

POP 서비스의 경우 비밀번호 기반 로그인이 자동으로 사용 가능하게 됩니다.

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

POP 서비스를 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o service.pop.enable -v [ yes | no ]

포트 번호를 지정하려면 다음을 수행합니다.

configutil -o service.pop.port -v number

프로세스당 최대 네트워크 연결 수 설정 방법( 5.3.2 프로세스당 연결 수 참조):

configutil -o service.pop.maxsessions -v number

연결에 대한 최대 유휴 시간 설정( 5.3.4 유휴 연결 해제 참조):

configutil -o service.pop.idletimeout -v number

프로세스당 최대 스레드 수 설정( 5.3.3 프로세스당 스레드 수 참조):

configutil -o service.pop.maxthreads -v number

최대 프로세스 수 설정 방법( 5.3.1 프로세스 수 참조):

configutil -o service.pop.numprocesses -v number

SSL에서의 POP를 사용하려면 다음을 수행합니다.


configutil -o service.pop.enablesslport -v 1
configutil -o service.pop.sslport -v 995

SSL이 올바르게 구성된 경우 TLS도 지원됩니다.

프로토콜 시작 배너를 지정하려면 다음을 수행합니다.

configutil -o service.pop.banner -v banner

5.6 IMAP 서비스 구성

configutil 명령을 사용하여 Messaging Server IMAP 서비스의 기본 구성을 수행할 수 있습니다. 이 절에서는 더 일반적인 몇 가지 IMAP 서비스 옵션이 제공됩니다. 전체 목록은 Sun Java System Messaging Server 6.3 Administration Reference의 3 장, Messaging Server Configuration에서 확인할 수 있습니다. 자세한 내용은 다음을 참조하십시오.

명령줄: 다음과 같이 명령줄에서 IMAP 속성에 대한 값을 설정할 수 있습니다.

IMAP 서비스를 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o service.imap.enable -v [ yes | no ]

포트 번호를 지정하려면 다음을 수행합니다.

configutil -o service.imap.port -v number

SSL을 통한 IMAP에 별개의 포트를 사용하려면 다음을 수행합니다.

configutil -o service.imap.enablesslport -v [ yes | no ]

SSL을 통한 IMAP에 사용할 포트 번호를 지정하려면 다음을 수행합니다.

configutil -o service.imap.sslport -v number

IMAP 서비스에 대한 비밀번호 로그인을 사용 또는 사용하지 않으려면 다음을 수행합니다.

configutil -o service.imap.plaintextmincipher -v value

value가 > 0이면 보안 계층(SSL 또는 TLS)이 활성화되지 않은 경우 일반 텍스트 비밀번호를 사용할 수 없게 됩니다. 사용자는 로그인하려면 네트워크상에서 비밀번호가 공개되는 것을 방지하는 SSL 또는 TLS를 클라이언트에서 사용 가능하게 해야 합니다. 기본값은 0입니다.

프로세스당 최대 네트워크 연결 수 설정( 5.3.2 프로세스당 연결 수 참조):

configutil -o service.imap.maxsessions -v number

연결에 대한 최대 유휴 시간 설정( 5.3.4 유휴 연결 해제 참조):

configutil -o service.imap.idletimeout -v number

프로세스당 최대 스레드 수 설정( 5.3.3 프로세스당 스레드 수 참조):

configutil -o service.imap.maxthreads -v number

최대 프로세스 수 설정( 5.3.1 프로세스 수 참조):

configutil -o service.imap.numprocesses -v number

프로토콜 시작 배너를 지정하려면 다음을 수행합니다.

configutil -o service.imap.banner -v banner

5.6.1 IMAP IDLE 구성

RFC 2177에 정의된 IMAP 지정에 대한 IMAP IDLE 확장을 사용하여 IMAP 서버는 새 메시지가 도착하거나 사용자의 메일함에 다른 업데이트가 적용될 경우 메일 클라이언트에게 알립니다. IMAP IDLE 기능의 장점은 다음과 같습니다.

5.6.1.1 전제 조건

IMAP IDLE 기능은 ENS(Event Notification Service)를 사용하여 알림을 전파합니다. IMAP IDLE를 사용하려면 다음 ENS 구성 요소를 구성해야 합니다.

Messaging Server에 대한 ENS 구성 방법에 대한 자세한 내용은 Sun Java System Communications Services Event Notification Service Guide를 참조하십시오.

iBiff 알림 플러그 인 구성에 대한 자세한 내용은 B.1 Messaging Server에서 ENS Publisher 로드을 참조하십시오.

ProcedureIMAP IDLE 구성 방법

  1. 메시지 저장소를 실행하는 호스트의 연결만 허용하도록 enpd 서버를 구성합니다.

    연결을 메시지 저장소 호스트로 제한하려면 ENS_ACCESS 환경 변수를 설정합니다. 환경 변수는 enpd에 액세스할 수 있는 권한 목록을 설정합니다. 구문은 다음과 같습니다.


    setenv ENS_ACCESS 'allowdeny ipaddress|mask;
allowdeny ipaddress|mask; ...'

    여기서

    allowdeny

    +(허용하도록 지정) 또는 —(거부하도록 지정)

    ipaddress

    점으로 구분된 십진수 형식의 IP 주소 지정

    mask

    점으로 구분된 십진수 형식의 IP 주소 마스크 지정

    예:

    다음 예에서는 로컬 호스트에만 액세스할 수 있습니다.


    setenv ENS_ACCESS '+127.0.0.1|255.255.255.255'

    다음 예에서는 로컬 호스트와 모든 IP 주소 192.168.0.*(192.168.0.17 제외)에 액세스할 수 있습니다.


    setenv ENS_ACCESS '+192.168.0.1|255.255.255.0;+127.0.0.1|255.255.255.255; \
-192.168.0.17;255.255.255.255'

  2. configutil 유틸리티를 실행하여 ENS 서버가 실행되고 있는 호스트의 이름을 지정합니다.


    cd msg-svr-base
./configutil -o local.store.notifyplugin.enshost -v "ipaddress"

    여기서 ipaddress는 ENS 호스트 시스템의 점으로 구분된 십진수 IP 주소를 지정합니다.

    예: 


    cd msg-svr-base
./configutil -o local.store.notifyplugin.enshost -v "127.0.0.1"

  3. ENS 알림에 사용할 이벤트 키를 지정합니다.

    ENS 이벤트 키(ensEventKey)가 기본값으로 설정되어 있는 경우 IMAP IDLE가 작동하지 않습니다.

    ensEventKey 값을 %M으로 끝나도록 구성해야 합니다. %M 문자열은 이벤트가 발생한 메일함의 이름으로 교체되는 대체 코드입니다.

    다음 configutil 명령을 실행합니다. 


    ./configutil -o local.store.notifyplugin.enseventkey -v "eventkey"

    여기서 eventkey는 ENS에 사용되는 고유한 식별자입니다. 기본값은 enp://127.0.0.1/store입니다. 이벤트 키의 호스트 이름 부분은 ENS가 실행 중인 호스트를 결정하는 데 사용되지 않으며, 식별자의 일부일 뿐입니다.

    예: 


    ./configutil -o local.store.notifyplugin.enseventkey -v "enp://127.0.0.1/store/%M"

  4. libibiff 알림 플러그 인 파일을 로드하여 Messaging Server용 ENS Publisher를 활성화합니다.

    다음 configutil 명령을 실행합니다.


    ./configutil -o local.store.notifyplugin -v "msg-svr-base/lib/libibiff"

  5. 받는 메일함이 아니라 모든 사용자 메일함에서 알림을 전송할 수 있습니다.

    기본적으로 알림은 받은 메일함에서 발생한 이벤트에 의해서만 생성됩니다. 그러나 IMAP IDLE RFC(2177)에는 모든 메일함에서 이벤트가 발생할 때마다 IDLE에서 클라이언트에게 알리도록 지정되어 있습니다.

    RFC를 준수하려면 IMAP IDLE 기능에서 모든 메일함에 대해 알림을 활성화해야 합니다. 그렇지 않으면 IMAP 서버가 IDLE 기능을 광고하지 않습니다.

    모든 메일함에 대해 알림을 구성하려면 configutil 명령 noneinbox 값을 1로 설정합니다.


    ./configutil -o local.store.notifyplugin.noneinbox.enable -v 1

    여기서 -v 1은 모든 메일함에서 알림을 활성화합니다.

  6. Messaging Server를 중지하고 다시 시작합니다.


    cd msg-svr-base/sbin

./stop-msg

./start-msg

  7. IMAP 서비스에 IDLE 기능이 포함되어 있는지 확인합니다. 텔넷을 사용하여 IMAP 호스트 및 포트에 연결합니다.


    telnet IMAP_hostname port

    예: 


    telnet myhost imap
trying 192.18.01.44 ... 
connected to myhost.siroe.com

* OK [CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS
CHILDREN BINARY UNSELECT SORT LANGUAGE STARTTLS IDLE XSENDER X-NETSCAPE
XSERVERINFO X-SUN-SORT X-SUN-IMAP X-ANNOTATEMORE AUTH=PLAIN]
myhost.siroe.com IMAP4 service (Sun Java(tm) System 
Messaging Server 6.3-0.05 (built Feb 7 2006))

5.7 HTTP 서비스 구성

Messaging Server는 Messenger Express 및 Communications Express라는 HTTP 메일 클라이언트를 지원합니다. POP 및 IMAP 클라이언트는 라우팅 또는 전달을 위해 Messaging Server MTA에 메일을 직접 보내지만 HTTP 클라이언트는 Webmail Server(mshttpd 또는 Messaging Server http 데몬이라고도 함)라는 특수 웹 서버에 메일을 보냅니다. 메시지의 대상에 따라 Webmail Server는 라우팅을 위해 아웃바운드 MTA에 메일을 직접 보내거나 IMAP를 사용하여 백엔드 메시지 저장소 중 하나에 메일을 보냅니다. 이는 그림 5–1에 표시되어 있습니다. Communications Express Server는 Webmail Server를 통해 요청을 라우팅합니다.

그림 5–1 HTTP 서비스 구성 요소

이 그림은 Messaging Server에 대한 HTTP 서비스 구성 요소를 설명합니다.

이전 버전에서는 Webmail Server가 메시지 저장소에 직접 액세스했습니다. 현재 버전에서는 IMAP 서버를 통해 메시지 저장소에 액세스합니다. 이 방법은 다음과 같은 장점이 있습니다.

이전 버전에서는 MEM이 HTTP 클라이언트 요청을 받아서 백엔드 메시지 저장소의 해당 Webmail Server에 전달합니다. 따라서 mshttpd 복사본을 모든 백엔드 서버에 설치해야 했습니다. 이 버전에서는 Webmail Server가 HTTP 클라이언트 전자 메일 요청을 받는 프런트엔드 서버 역할을 합니다. 또한 이러한 요청을 SMTP 또는 IMAP 호출로 변환한 다음 백엔드 메시지 저장소의 해당 IMAP 서버나 MTA에게 전달합니다. Messaging Server가 웹 기반 전자 메일에만 사용되는 경우 IMAP를 활성화해야 합니다.

5.7.1 HTTP 서비스 구성

대부분의 HTTP 구성 매개 변수는 POP 및 IMAP 서비스에 사용할 수 있는 매개 변수와 비슷합니다. 여기에는 연결 설정 및 프로세스 설정을 위한 매개 변수가 포함됩니다. 이 절에서는 더 일반적인 몇 가지 HTTP 서비스 옵션이 제공됩니다. 전체 목록은 Sun Java System Messaging Server 6.3 Administration Reference의 configutil Parameters에서 확인할 수 있습니다. 자세한 내용은 다음을 참조하십시오.

사용자가 액세스하는 각 IMAP 서버에 대해 Webmail Server는 IMAP 포트, SSL 사용 여부 및 사용자 로그인에 사용할 관리자 자격 증명을 알고 있어야 합니다. 이 작업을 수행하는 configutil 매개 변수는 다음과 같습니다.

local.service.proxy.imapport[.hostname ] — 연결할 IMAP 포트입니다(기본값:143).

local.service.proxy.imapssl — SSL를 활성화합니다(기본값: 없음).

local.service.proxy.admin[.hostname ] — 관리자 아이디입니다.

local.service.proxy.adminpass[.hostname ] — 관리자 비밀번호입니다.

이러한 매개 변수는 전역적(모든 IMAP 백엔드 서버에 적용)으로 설정하거나, 옵션 이름에 백엔드의 정규화된 도메인 이름을 추가하여 IMAP 백엔드 서버별로 설정할 수 있습니다.

SSL을 통한 IMAP를 사용하려면 mshttpd를 SSL HTTP 서버로 구성하고 mshttpd 인증서 데이터베이스가 IMAP 백엔드의 CA를 신뢰해야 합니다. 또한 service.http.sslusessl을 활성화해야 합니다. IMAP를 실행하는 백엔드 메시지 저장소에서 자체 서명된 인증서(예: generate-certDB를 통해 생성된 인증서)를 사용하는 경우 해당 인증서를 프런트엔드 mshttpd 데몬 프록시에 추가해야 합니다.

local.service.proxy.admin/pass를 설정하지 않은 경우 로그인이 거부되고 메일 서버를 사용할 수 없습니다.라는 오류 메시지가 발생합니다. 관리자는 서버 로그에서 자세한 내용을 확인하십시오.또한 http 로그에 누락된 구성 옵션이 나열됩니다.

명령줄에서 추가 HTTP 속성 값을 다음과 같이 설정할 수 있습니다.

HTTP 서비스를 활성화하거나 비활성화하려면 다음을 수행합니다.

configutil -o service.http.enable -v [ yes | no ]

기본적으로 HTTP 서비스는 라우팅 또는 전달을 위해 보내는 웹 메일을 로컬 MTA로 전송합니다. 예를 들어, 사이트가 호스팅 서비스이며 대부분의 수신자가 로컬 호스트 시스템과 다른 도메인에 있을 경우 메일을 원격 MTA로 보내도록 HTTP 서비스를 구성할 수 있습니다. 웹 메일을 원격 MTA로 보내려면 원격 호스트의 이름과 SMTP 포트 번호를 지정해야 합니다. 포트 번호를 지정하려면 다음을 수행합니다.

configutil -o service.http.port -v number

SSL을 통한 HTTP에 별개의 포트를 사용하려면 다음을 수행합니다.

configutil -o service.http.enablesslport -v [ yes | no ]

SSL을 통한 HTTP에 사용할 포트 번호를 지정하려면 다음을 수행합니다.

configutil -o service.http.sslport -v number

비밀번호 기반 로그인을 활성화하거나 비활성화하려면 다음을 수행합니다.

configutil -o service.http.plaintextmincipher -v value

value가 > 0이면 보안 계층(SSL 또는 TLS)이 활성화되지 않은 경우 일반 텍스트 비밀번호를 사용할 수 없게 됩니다. 사용자는 로그인하려면 네트워크상에서 비밀번호가 공개되는 것을 방지하는 SSL 또는 TLS를 클라이언트에서 사용 가능하게 해야 합니다. 기본값은 0입니다.

프로세스당 최대 네트워크 연결 수 설정( 5.3.2 프로세스당 연결 수 참조):

configutil -o service.http.maxsessions -v number

연결에 대한 최대 유휴 시간 설정( 5.3.4 유휴 연결 해제 참조)

configutil -o service.http.idletimeout -v number

클라이언트 세션에 대한 최대 유휴 시간 설정( 5.3.5 HTTP 클라이언트 로그아웃 참조):

configutil -o service.http.sessiontimeout -v number

프로세스당 최대 스레드 수를 설정하려면 다음을 수행합니다.

configutil -o service.http.maxthreads -v number

최대 프로세스 수를 설정하려면 다음을 수행합니다.

configutil -o service.http.numprocesses -v number

HTTP 클라이언트가 첨부 파일이 있는 메시지를 생성하면 첨부 파일은 서버로 업로드되어 파일에 저장됩니다. HTTP 서비스는 라우팅 또는 전달을 위해 메시지를 MTA로 보내기 전에 첨부 파일을 검색하고 메시지를 생성합니다. 기본 첨부 파일 스풀 디렉토리를 사용하거나 대체 디렉토리를 지정할 수 있습니다. 또한 첨부 파일에 허용되는 최대 크기를 지정할 수도 있습니다. 클라이언트에 보내는 메일의 첨부 파일 스풀 디렉토리를 지정하려면 다음 명령을 사용합니다. 여기에는 base64로 인코딩된 모든 첨부 파일이 포함되며 base64 인코딩은 33%의 추가 공간이 필요하다는 점을 유의하십시오. 따라서 매개 변수의 제한이 5MB일 경우 메시지 하나와 첨부 파일의 최대 크기는 약 3.75MB가 됩니다.

configutil -o service.http.spooldir -v dirpath

최대 메시지 크기를 지정하려면 다음을 수행합니다.

configutil -o service.http.maxmessagesize -v size

여기에서 size는 바이트 수입니다. 여기에는 base64로 인코딩된 모든 첨부 파일이 포함되며 base64 인코딩은 33%의 추가 공간이 필요하다는 점을 유의하십시오. 따라서 매개 변수의 제한이 5MB일 경우 메시지 하나와 첨부 파일의 최대 크기는 약 3.75MB가 됩니다.

대체 MTA 호스트 이름을 지정하려면 다음을 수행합니다.

configutil -o service.http.smtphost -v hostname

대체 MTA 호스트 이름의 포트 번호를 지정하려면 다음을 수행합니다.

configutil -o service.http.smtpport -v portnum