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

17장 메일 필터링 및 액세스 제어

이 장에서는 메일의 소스(보낸 사람, IP 주소 등) 또는 헤더 문자열에 기초하여 메일을 필터링하는 방법에 대해 설명합니다. 두 개의 메일 필터링 기법, 즉 매핑 테이블을 사용한 MTA에 대한 액세스 제어와 Sieve 서버측 규칙(SSR)이 사용됩니다.

매핑 테이블을 사용하여 MTA에 대한 액세스를 제한하면 From: 및 To: 주소, IP 주소, 포트 번호, 소스 또는 대상 채널 등에 기초하여 메일을 필터링할 수 있습니다. 매핑 테이블은 SMTP 중계를 활성화 또는 비활성화할 수 있게 합니다. Sieve는 헤더에서 발견된 문자열에 기초하여 메일을 필터링할 수 있게 하는 메일 필터링 스크립트이며메일 본문에서는 작동하지 않습니다.

봉투 수준 제어가 필요한 경우에는 매핑 테이블을 사용하여 메일을 필터링하고 헤더 기반 제어가 필요한 경우에는 Sieve 서버측 규칙을 사용합니다.

이 장은 다음 두 부분으로 구성됩니다.

1부. 매핑 테이블. 관리자가 특정 매핑 테이블을 구성하여 MTA 서비스에 대한 액세스를 제어할 수 있게 합니다. 관리자는 Messaging Server를 통해 메일을 주고 받을 수 있는 사람과 그렇지 않은 사람을 제어할 수 있습니다.

2부. 메일함 필터. 사용자와 관리자가 메일 헤더에서 찾은 문자열을 기초로 메일을 필터링하고, 필터링된 이런 메일에 수행할 작업을 지정할 수 있습니다. Sieve 필터 언어를 사용하여 채널, MTA 또는 사용자 수준에서 필터링할 수 있습니다.

1부. 매핑 테이블

1부는 다음 내용으로 구성되어 있습니다.

매핑 테이블을 사용한 액세스 제어

특정 매핑 테이블을 구성하여 메일 서비스에 대한 액세스를 제어할 수 있습니다. 이러한 매핑 테이블을 사용하면 메일을 전송 및/또는 수신할 수 있거나 그렇게 할 수 없는 사람을 제어할 수 있습니다. 표 17–1에는 이 절에 설명된 매핑 테이블이 나열되어 있습니다. FROM_ACCESS, MAIL_ACCESSORIG_MAIL_ACCESS 매핑에 제공되는 응용 프로그램 정보 문자열에는 HELO/ EHLO SMTP 명령에서 요구된 시스템 이름도 포함됩니다. 이 이름은 문자열 끝에 표시되며 슬래시(/)로 나머지 문자열(일반적으로 “SMTP”)과 구분합니다. 요구된 시스템 이름은 일부 웜 및 바이러스를 차단하는 데 유용하게 사용될 수 있습니다.

액세스 제어 매핑 테이블 - 작업

모든 매핑 테이블과 마찬가지로 액세스 제어 매핑 테이블은 동일한 일반 형식을 가집니다( 매핑 파일 참조). 즉, 매핑 테이블 이름이 맨 앞에 오고 그 뒤에 공백이 있으며 맨 뒤에 하나 이상의 매핑 항목이 오는 형식입니다. 매핑 항목은 왼쪽에 있는 검색 패턴과 오른쪽에 있는 템플리트로 구성됩니다. 검색 패턴은 특정 메일을 필터링하며 템플리트는 메일에 대해 수행할 작업을 지정합니다. 예를 들면 다음과 같습니다.

SEND_ACCESS

 *|Elvis1@sesta.com|*|*      $Y
 *|Nelson7@sesta.com|*|*     $Y
 *|AkiraK@sesta.com|*|*      $Y
 *|*@sesta.com|*|*           $NMail$ Blocked

다음 예는 sesta.com 도메인에서 Elvis1, Nelson, AkiraK 의 전자 메일을 제외한 모든 전자 메일을 차단합니다.

액세스 제어 매핑 항목의 검색 패턴은 세로 막대(|)로 구분된 여러 검색 기준으로 구성됩 니다. 검색 기준의 순서는 액세스 매핑 테이블에 따라 다르며 이후의 절에서 설명합니다. 예를 들어 SEND_ACCESS 매핑 테이블의 검색 형식은 다음과 같습니다.

src-channel|from-address|dst-channel|to-address

src-channel은 메일이 대기 중인 채널, from-address는 메일을 보낸 사람의 주소, dst-channel은 메일이 대기될 채널, to-address는 메일 주소가 지정된 주소입니다. 이 네 필드에 별표를 사용하면 해당 필드는 모든 채널 또는 주소와 일치하게 됩니다.


주 –

mappings 파일을 수정할 때마다 구성을 다시 컴파일해야 합니다( MTA 구성 컴파일 참조).


표 17–1 액세스 제어 매핑 테이블

매핑 테이블 

설명 

SEND_ACCESS( SEND_ACCESS 및 ORIG_SEND_ACCESS 테이블 참조)

봉투 From 주소와 봉투 To 주소, 소스 및 대상 채널을 기준으로 받는 연결을 차단하는 데 사용됩니다. To 주소는 다시 쓰기, 별칭 확장 등이 수행된 뒤 검사됩니다.

ORIG_SEND_ACCESS( SEND_ACCESS 및 ORIG_SEND_ACCESS 테이블 참조)

봉투 From 주소와 봉투 To 주소, 소스 및 대상 채널을 기준으로 받는 연결을 차단하는 데 사용됩니다. To 주소는 다시 쓴 다음, 별칭 확장 전에 검사됩니다.

MAIL_ACCESS( MAIL_ACCESS 및 ORIG_MAIL_ACCESS 매핑 테이블 참조)

SEND_ACCESSPORT_ACCESS 테이블에서 발견한 결합된 정보(PORT_ACCESS에서 발견한 IP 주소 및 포트 번호 정보와 결합된 SEND_ACCESS에서 발견된 채널 및 주소 정보)에 기초하여 받는 연결을 차단하는 데 사용됩니다.

ORIG_MAIL_ACCESS( MAIL_ACCESS 및 ORIG_MAIL_ACCESS 매핑 테이블 참조)

ORIG_SEND_ACCESSPORT_ACCESS 테이블에서 발견한 결합된 정보(PORT_ACCESS에서 발견한 IP 주소 및 포트 번호 정보와 결합된 ORIG_SEND_ACCESS에서 발견된 채널 및 주소 정보)에 기초하여 받는 연결을 차단하는 데 사용됩니다.

FROM_ACCESS( FROM_ACCESS 매핑 테이블 참조)

봉투 From 주소를 기준으로 메일을 필터링하는 데 사용됩니다. To 주소가 부적절한 경우 이 테이블을 사용합니다.

PORT_ACCESS( PORT_ACCESS 매핑 테이블 참조)

IP 번호를 기준으로 받는 연결을 차단하는 데 사용됩니다. 

SEND_ACCESSORIG_SEND_ACCESS에 사용 가능한 주소 및 채널 정보와 IP 주소와 포트 번호 정보를 포함하여 PORT_ACCESS 매핑 테이블을 통해 사용 가능한 모든 정보를 사용할 수 있는 경우 MAIL_ACCESSORIG_MAIL_ACCESS 매핑이 가장 일반적입니다.

액세스 제어 매핑 테이블 플래그

표 17–2SEND_ACCESS, ORIG_SEND_ACCESS, MAIL_ACCESS, ORIG_MAIL_ACCESSFROM_ACCESS 매핑 테이블에 관련된 액세스 매핑 플래그입니다. PORT_ACCESS 매핑 테이블은 이와 약간 다른 플래그 집합을 지원합니다(표 17–3 참조).

인수가 있는 플래그에서는 인수를 표에 나온 읽기 순서에 따라 정렬해야 합니다. 예를 들면 다음과 같습니다.

ORIG_SEND_ACCESS

  tcp_local|*|tcp_local|*     $N$D30|Relaying$ not$ allowed

이 경우에 올바른 순서는 지연 기간 다음에 거부 문자열이 오는 것입니다. 플래그 자체는 임의의 순서가 될 수 있습니다. 따라서 다음 항목의 결과는 동일합니다.


30|Relaying$ not$ allowed$D$N
$N30|Relaying$ not$ allowed$D
30|$N$DRelaying$ not$ allowed
표 17–2 액세스 매핑 플래그

플래그 

설명 

$A

SASL이 사용된 경우 설정합니다. 특수 플래그 검사를 참조하십시오.

$B

메일을 bitbucket으로 리디렉션합니다. 

$D

전달 지연 확인이 요청된 경우(FROM_ACCESS에서는 사용할 수 없음) 설정합니다. 특수 플래그 검사를 참조하십시오.

$F

전달 실패 확인이 요청된 경우(FROM_ACCESS에서는 사용할 수 없음) 설정합니다. 특수 플래그 검사를 참조하십시오.

$H

메일을 .HELD 파일로 보관합니다.

$S

전달 성공 확인이 요청된 경우(FROM_ACCESS에서는 사용할 수 없음) 설정합니다. 특수 플래그 검사를 참조하십시오.

$T

TLS가 사용된 경우 설정합니다. 특수 플래그 검사를 참조하십시오.

$U 

ORIG_SEND_ACCESS, SEND_ACCESS, ORIG_MAIL_ACCESSMAIL_ACCESS에서 사용될 경우 매핑의 시작 부분에서 단일 정수 인수를 가져오며 이에 따라 MM_DEBUG 값을 설정합니다. 또한 가능한 경우 채널 수준 디버깅도 사용 가능하게 합니다. 결과적으로 소스 IP 주소, 원래 주소, 수신자 주소 등의 항목에 기초하여 디버깅을 사 용 가능하게 합니다.

$Y

액세스를 허용합니다. 

$V

모든 수신자에 대해 삭제를 수행합니다. 

$Z

모든 수신자에 대해 jettison을 수행합니다. 

인수가 있는 플래그, 인수 읽기 순서에 따라 + (이 목록을 알파벳 순서로 정렬하지 마십시오!)

$Uinteger

매핑의 시작 부분에서 단일 정수 인수를 가져오며 이에 따라 MM_DEBUG를 설정합니다. 또한 가능한 경우 채널 수준 디버깅도 사용 가능하게 합니다. 결과적으로 소스 IP 주소, 원래 주소, 수신자 주소 등의 항목에 기초하여 디버깅을 사용 가능하게 할 수 있습니다. 

$Jaddress

원본 봉투 From: 주소를 지정된 address로 대체합니다.

$Kaddress

* ++ 원래의 Sender: 주소를 지정된 address로 대체합니다.

$Iuser|identifier

지정된 사용자의 그룹 아이디를 확인합니다. 

$<string

+++ 검사가 일치하면 string을 syslog(UNIX, user.notice 기능 및 심각도) 또는 이벤트 로그(NT)로 보냅니다.+++

$>string

+++ 액세스가 거부되면 string을 syslog(UNIX, user.notice 기능 및 심각도) 또는 이벤트 로그(NT)로 보냅니다.

$Ddelay

delay 시간 간격(1/100초)에 대한 지연 응답입니다. 양수 값을 사용하면 트랜잭션의 각 명령에 지연이 적용되며, 음수 값을 사용하면 주소 전달(FROM_ACCESS 테이블에 대한 SMTP MAIL FROM: 명령, 다른 테이블에 대한 SMTP RCPT TO: 명령)에만 지연이 적용됩니다.

$Ttag

tag 접두어가 사용됩니다.

$Aheader

메일에 헤더 행 header를 추가합니다.

$Gconversion_tag

ORIG_SEND_ACCESS, SEND_ACCESS, ORIG_MAIL_ACCESSMAIL_ACCESS에서 사용될 경우 매핑 결과에서 값을 읽고 이를 현재 수신자에게 적용될 변환 태그 집합으로 처리합니다. FROM_ACCESS와 함께 사용될 경우 변환 태그가 모든 수신자에게 적용됩니다. $G의 위치는 매핑에서 읽은 인수 시퀀스에서 $A(헤더 주소) 다음입니다. 메일 변환 태그를 참조하십시오.

$Sx,y,z

* 세로 막대(|)로 구분된 추가 인수를 매핑 결과에서 읽습니다. 이 인수는 쉼표로 구분된 하나에서 세 개의 정수 값으로 구성됩니다. 첫 번째 값은 트랜잭션에 대한 최소 blocklimit를 새로 설정하고, 두 번째 값은 최소 ecipientlimit를 새로 설정하며, 세 번째 값은 최소 recipientcutoff를 새로 설정합니다. 이 인수는 모든 캡처 인수를 읽은 후에 매핑 결과에서 읽습니다. 절대 메일 크기 제한 지정을 참조하십시오.

$Xerror-code

메일 거부 시 지정된 error-code 확장 SMTP 오류 코드를 발행합니다.

$,spamadjust_arg

액세스 매핑 테이블에서 sieve spamadjust 작업을 수행할 수 있습니다. 인수는 spamadjust 인수와 동일한 형식을 취합니다. 이러한 매핑의 일부는 수신자별 기준으로 적용된다는 점에 유의하십시오. 수행된 spamadjust 작업은 모든 수신자에 적용됩니다.

$Nstring

선택적 오류 텍스트 string을 사용하여 액세스를 거부합니다.

$Fstring

$N string에 대한 동의어, 즉 선택적 오류 텍스트 string을 사용하여 액세스를 거부합니다.

* FROM_ACCESS 테이블에만 사용할 수 있습니다.

+ 인수가 있는 여러 개의 플래그를 사용하려면 인수를 세로 막대 문자 |로 구분하고 이 테이블에 나열된 순서대로 인수를 배치합니다.

++ $K 플래그가 FROM_ACCESS 매핑 테이블에 적용되려면 소스 채널에 authrewrite 키워드가 포함되어야 합니다.

+++ 문제가 있는 보낸 사람을 처리할 때는 서비스 거부 공격을 방지하기 위해 $D 플래그를 사용하는 것이 좋습니다. 특히 모든 $> 항목 또는 액세스를 거부하는 $< 항목에는 $D를 사용하는 것이 좋습니다.

SEND_ACCESS 및 ORIG_SEND_ACCESS 테이블

SEND_ACCESSORIG_SEND_ACCESS 매핑 테이블을 사용하여 메일을 송수신할 수 있거나 할 수 없는 사용자 또는 둘 다를 제어할 수 있습니다. 액세스 검사는 메일 봉투 From: 주소와 봉투 To: 주소에서 사용 가능하며 메일을 전송한 채널과 대상 채널을 알 수 있습니다.

SEND_ACCESS 또는 ORIG_SEND_ACCESS 매핑 테이블이 있으면 MTA를 통과하여 전달되는 모든 메일의 각 수신자에 대해 MTA는 다음 형식의 문자열로 테이블을 스캔합니다(세로 막대 문자 | 사용).

src-channel|from-address|dst-channel|to-address

src-channel은 메일이 대기 중인 채널이고 from-address는 메일을 보낸 사람의 주소, dst-channel은 메일이 대기될 채널, to-address는 메일 주소가 지정된 주소입니다. 이 네 필드에 별표를 사용하면 해당 필드는 모든 채널 또는 주소와 일치하게 됩니다.

여기서 주소는 봉투 주소, 즉 봉투 From: 주소와 봉투 To: 주소입니다. SEND_ACCESS의 경우 봉투 To: 주소는 다시 쓰기, 별칭 확장 등이 수행된 후 검사되고, ORIG_SEND_ACCESS의 경우 원래 지정된 봉투 To: 주소를 다시 쓴 다음, 그리고 별칭 확장 전에 검사됩니다.

검색 문자열이 패턴(즉, 테이블 항목의 왼쪽)과 일치하면 매핑의 결과 출력이 검사됩니다. 출력에 플래그 $Y 또는 $y가 포함된 경우 해당 To: 주소에 대한 대기가 허용됩니다. 출력에 플래그 $N, $n, $F 또는 $f가 포함되어 있으면 해당 주소에 대한 대기가 거부됩니다. 거부된 경우 선택적 거부 텍스트가 매핑 출력에 표시될 수 있습니다. 이 문자열은 MTA가 표시하는 거부 오류에 포함됩니다. 문자열이 출력되지 않으면($N, $n, $F 또는 $f 플래그 제외) 기본 거부 텍스트가 사용됩니다. 추가 플래그에 대한 설명은 액세스 제어 매핑 테이블 플래그를 참조하십시오.

MTA 옵션 ACCESS_ORCPT를 1로 설정하면 원래 수신자(원래 수신자(ORCPT) 주소를 포함하는 SEND_ACCESS, ORIG_SEND_ACCESS, MAIL_ACCESSORIG_MAIL_ACCESS 매핑 테이블로 전달되는 검사 값에 수직 막대로 구분된 필드가 또 하나 추가됩니다. 메일에 ORCPT 주소가 없으면 수정되지 않은 원래 RCPT TO: 주소가 대신 사용됩니다. 기본값은 0이고 검사 값은 마지막에 있습니다.

src-channel|from-address|dst-channel|to-address|ORCPT_address

다음 예에서는 mail, Pine 등의 UNIX 사용자 에이전트가 보낸 메일(로컬, l, 채널 및 메일에서 인터넷으로 전송)이 일종의 TCP/IP 채널로 나갑니다. 여기서는 포스트마스터를 제외한 이러한 로컬 사용자가 인터넷으로 메일을 보낼 수 없지만 인터넷에서 메일을 받을 수는 있다고 가정합니다. 이 경우 아래 예에 표시된 SEND_ACCESS 매핑 테이블을 사용하는 것이 이러한 제한을 적용하는 한 가지 방법이 됩니다. 매핑 테이블에서 로컬 호스트 이름을 sesta.com으로 가정합니다. 채널 이름 “tcp_*”에서 와일드 카드가 사용되어 가능한 모든 TCP/IP 채널 이름(예: tcp_local)과 일치합니다.


예 17–1 SEND_ACCESS 매핑 테이블


SEND_ACCESS

   *|postmaster@sesta.com|*|*    $Y
   *|*|*|postmaster@sesta.com    $Y
   l|*@sesta.com|tcp_*|*         $NInternet$ postings$ are$ not$ permitted

            

거부 메일에 공백을 입력하려면 달러 기호를 사용합니다. 달러 기호가 없으면 거부가 일찍 완료되어 “Internet postings are not permitted” 대신 “Internet”만 표시됩니다. 이 예에서는 PC 기반 메일 시스템이나 POP 또는 IMAP 클라이언트 등 “로컬” 게시의 소스에 대한 다른 가능성은 무시합니다.


주 –

MTA 거부 오류 텍스트를 메일을 보내려는 사용자에게 실제로 표시할 것인지 여부는 메일을 보내려는 클라이언트가 결정합니다. SEND_ACCESS를 사용하여 받는 SMTP 메일을 거부하는 경우 MTA는 선택적 거부 텍스트를 비롯하여 SMTP 거부 코드만 발행합니다. 즉, 이 정보를 사용하여 원래 보낸 사람에게 보낼 바운스 메일을 구성할 것인지는 SMTP 클라이언트가 결정합니다.


MAIL_ACCESS 및 ORIG_MAIL_ACCESS 매핑 테이블

MAIL_ACCESS 매핑 테이블은 SEND_ACCESSPORT_ACCESS 매핑 테이블의 수퍼 세트입니다. 여기에서는 SEND_ACCESS의 채널과 주소 정보를 PORT_ACCESS의 IP 주소 및 포트 번호 정보와 조합합니다. 마찬가지로, ORIG_MAIL_ACCESS 매핑 테이블은 ORIG_SEND_ACCESSPORT_ACCESS 매핑 테이블의 수퍼 세트입니다. MAIL_ACCESS에 대한 검사 문자열 형식은 다음과 같습니다.

port-access-probe-info|app-info|submit-type|send_access-probe-info

마찬가지로 ORIG_MAIL_ACCESS의 검사 문자열 형식은 다음과 같습니다.

port-access-probe-info|app-info|submit-type|orig_send_access-probe-info

여기서 받는 SMTP 메일의 경우 port-access-probe-info는 보통 PORT_ACCESS 매핑 테이블 검사에 포함된 모든 정보로 구성되는 반면, 그 외의 경우에는 비어 있는 상태가 됩니다. app-info에는 HELO/EHLO SMTP 명령에서 요구한 시스템 이름이 포함됩니다. 이 이름은 문자열 끝에 표시되며 슬래시(/)로 나머지 문자열(일반적으로 “SMTP”)과 구분합니다. 요구된 시스템 이름은 일부 웜 및 바이러스를 차단하는 데 유용하게 사용될 수 있습니다. submit-type은 Messaging Server로 메일이 전송된 방법에 따라 MAIL, SEND, SAML, SOML 중 하나가 될 수 있습니다. 일반적으로 그 값은 MAIL이며 이는 메일로 전송된다는 의미입니다. 즉, 브로드캐스트 요청(또는 조합된 브로드캐스트/메일 요청)이 SMTP 서버로 전송된 경우 SEND, SAML 또는 SOML이 발생할 수 있습니다. 또한 MAIL_ACCESS 매핑의 경우 send-access-probe-info는 일반적으로 SEND_ACCESS 매핑 테이블 검사에 포함된 모든 정보로 구성됩니다. orig-send-access-probe-info는 일반적으로 ORIG_MAIL_ACCESS 매핑과 유사하게 ORIG_SEND_ACCESS 매핑 테이블 검사에 포함된 모든 정보로 구성됩니다.

MTA 옵션 ACCESS_ORCPT을 1로 설정하면 원래 수신자(ORCPT) 주소를 포함하는 SEND_ACCESS, ORIG_SEND_ACCESS , MAIL_ACCESSORIG_MAIL_ACCESS 매핑 테이블로 전달되는 검사 값에 수직 막대로 구분된 필드가 또 하나 추가됩니다. 메일에 ORCPT 주소가 없으면 수정되지 않은 원래 RCPT TO: 주소가 대신 사용됩니다. 기본값은 0이고 검사 값은 마지막에 있습니다. 예:


port-access-probe-info|app-info|submit-type|send_access-probe-info|ORCPT_address

받는 TCP/IP 연결 정보를 채널 및 주소 정보와 동일한 매핑 테이블에서 사용할 수 있는 경우에는 특정 IP 주소에서 보낸 메일에 표시되도록 허용되는 봉투 From: 주소를 지정하는 등의 제어를 보다 편리하게 수행할 수 있습니다. 이렇게 하면 전자 메일 위조의 가능성을 줄이거나 사용자가 자신의 POP 및 IMAP 클라이언트의 ’ From: 주소를 적절하게 설정하도록 유도할 수 있습니다. 예를 들어, 봉투 From: 주소 vip@siroe.com이 IP 주소 1.2.3.1 및 1.2.3.2에서 받는 메일에만 나타나도록 하고 1.2.0.0 서브넷에 있는 시스템으로부터 받는 메일의 봉투 From: 주소는 siroe.com에서 보낸 것으로 하려면 아래 예에 표시된 대로 MAIL_ACCESS 매핑 테이블을 사용할 수 있습니다.


예 17–2 MAIL_ACCESS 매핑 테이블


MAIL_ACCESS
 
! Entries for vip's two systems
!
  TCP|*|25|1.2.3.1|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|*  $Y
  TCP|*|25|1.2.3.2|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|*  $Y
!
! Disallow attempts to use vip's From: address from other
! systems
!
  TCP|*|25|*|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|*  \
      $N500$ Not$ authorized$ to$ use$ this$ From:$ address
!
! Allow sending from within our subnet with siroe.com From:
! addresses
!
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*|*@siroe.com|*|*  $Y
!
! Allow notifications through
!
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*||*|*  $Y
!
! Block sending from within our subnet with non-siroe.com
! addresses
!
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*|*|*|*  \
     $NOnly$ siroe.com$ From:$ addresses$ authorized

FROM_ACCESS 매핑 테이블

FROM_ACCESS 매핑 테이블은 메일을 보낼 수 있는 사용자를 제어하거나 인증된 주소를 가진 From: 주소를 무시하는 데 사용할 수 있습니다.

FROM_ACCESS 매핑 테이블에 대한 입력 검사 문자열은 MAIL_ACCESS 매핑 테이블에서 대상 채널과 주소를 제외하고 인증된 보낸 사람 정보(사용 가능한 경우)를 추가한 것과 같습니다. 따라서 FROM_ACCESS 매핑 테이블이 있는 경우 Messaging Server는 시도되는 각 메일 전송에 대해 다음 형식의 문자열을 가진 테이블을 검색합니다(세로 막대 문자 | 사용 주의).


port-access-probe-info|app-info|submit-type|src-channel|from-address|auth-from

여기서 받는 SMTP 메일의 경우 port-access-probe-info는 보통 PORT_ACCESS 매핑 테이블 검사에 포함된 모든 정보로 구성되는 반면, 그 외의 경우에는 비어 있는 상태가 됩니다. app-info에는 HELO/EHLO SMTP 명령에서 요구한 시스템 이름이 포함됩니다. 이 이름은 문자열 끝에 표시되며 슬래시(/)로 나머지 문자열(일반적으로 “SMTP”)과 구분합니다. 요구된 시스템 이름은 일부 웜 및 바이러스를 차단하는 데 유용하게 사용될 수 있습니다. submit-type은 MTA로 메일이 전송된 방법에 따라 MAIL, SEND, SAML, SOML 중 하나가 될 수 있습니다. 일반적으로 그 값은 MAIL이며 이는 메일로 전송된다는 의미입니다. 즉, 브로드캐스트 요청(또는 조합된 브로드캐스트/메일 요청)이 SMTP 서버로 전송된 경우 SEND, SAML 또는 SOML이 발생할 수 있습니다. src-channel은 메일을 보낸(메일을 대기열에 넣는) 채널, from-address는 메일을 최초로 보낸 사람의 주소이며 auth-from은 인증된 보낸 사람 주소(이 정보가 사용 가능한 경우)이고 인증된 정보를 사용할 수 없는 경우에는 비어 있습니다.

검사 문자열이 패턴(즉, 테이블 항목의 왼쪽)과 일치하면 매핑의 결과 출력이 검사됩니다. 출력에 플래그 $Y 또는 $y가 포함된 경우 해당 To: 주소에 대한 대기가 허용됩니다. 출력에 플래그 $N, $n, $F 또는 $f가 포함되어 있으면 해당 주소에 대한 대기가 거부됩니다. 거부된 경우 선택적 거부 텍스트가 매핑 출력에 표시될 수 있습니다. 이 문자열은 Messaging Server가 표시하는 거부 오류에 포함될 수 있습니다. 문자열이 출력되지 않으면($N, $n, $F 또는 $f 플래그 제외) 기본 거부 텍스트가 사용됩니다. 추가 플래그에 대한 설명은 액세스 제어 매핑 테이블 플래그를 참조하십시오.

FROM_ACCESS는 메일 발송자를 기준으로 전송 가능한 메일을 허용할지 여부를 결정하는 것 외에도 봉투 From: 주소를 $J 플래그를 통해 변경하거나 authrewrite 채널 키워드(받은 메일의 Sender: 헤더 주소 추가)의 결과를 $K 플래그를 통해 수정하는 데 사용할 수도 있습니다. 예를 들어, 이 매핑 테이블을 사용하여 다음과 같이 원래의 봉투 From: 주소를 인증된 주소로 바꿀 수 있습니다.


예 17–3 FROM_ACCESS 매핑 테이블


FROM_ACCESS

  *|SMTP|*|tcp_auth|*|       $Y
  *|SMTP|*|tcp_auth|*|*      $Y$J$3
            

FROM_ACCESS 매핑 테이블을 사용하여 일부 소스 채널의 0이 아닌 값에 대해 authrewrite를 설정한 결과를 수정할 때 인증된 주소가 글자 그대로 사용되는 경우에는 FROM_ACCESS를 사용하지 않아도 됩니다.

예를 들어, tcp_local 채널에 authrewrite 2를 설정한 경우에는 authrewrite만으로도 이 결과를 얻을 수 있기 때문에(인증된 주소를 그대로 추가) FROM_ACCESS 매핑 테이블이 필요하지 않습니다.


FROM_ACCESS

   *|SMTP|*|tcp_auth|*|     $Y
   *|SMTP|*|tcp_auth|*|*    $Y$K$3
         

하지만 FROM_ACCESS의 실제 용도는 아래 예에 표시된 대로 보다 복잡하고 세밀한 변경을 허용하는 것입니다. Sender: 헤더 행(SMTP AUTH 인증 전송자 주소 표시)을 받는 메일에 추가하려는 경우에는 authrewrite만 사용해도 됩니다. 하지만 SMTP AUTH 인증 전송자 주소가 봉투 From: 주소와 다른 경우에만 Sender: 헤더 행 등을 받는 메일에 추가하는(즉, 주소가 일치하는 경우에는 Sender: 헤더 행) 것으로 가정하고, 또한 봉투 From: 에 선택적 하위 주소 정보가 포함되어 있다는 이유만으로 SMTP AUTH와 봉투 From:을 서로 다른 것으로 간주하지 않는 것으로 가정합니다.


FROM_ACCESS
 
! If no authenticated address is available, do nothing
  *|SMTP|*|tcp_auth|*|              $Y
! If authenticated address matches envelope From:, do nothing
  *|SMTP|*|tcp_auth|*|$2*           $Y
! If authenticated address matches envelope From: sans
! subaddress, do nothing
   *|SMTP|*|tcp_auth|*+*@*|$2*@$4*    $Y
! Fall though to...
! ...authenticated address present, but didn't match, so force
! Sender: header
  *|SMTP|*|tcp_auth|*|*              $Y$K$3
         

PORT_ACCESS 매핑 테이블

디스패처는 IP 주소와 포트 번호를 기반으로 선택적으로 받는 연결을 수락하거나 거부할 수 있습니다. 디스패처는 시작 시에 PORT_ACCESS라는 매핑 테이블을 찾습니다. 이 테이블이 있으면 디스패처는 연결 정보를 다음 형식으로 구성합니다.

TCP|server-address|server-port|client-address|client-port

디스패처는 모든 PORT_ACCESS 매핑 항목에 대응시키려 시도합니다. 매핑 결과에 $N 또는 $F가 포함되어 있으면 연결이 즉시 닫힙니다. 매핑의 다른 결과는 연결이 수락되는 것을 나타냅니다. 거부 메일 다음에 선택적으로 $N 또는 $F가 올 수 있습니다. $N 또는 $F가 오는 경우 메일은 닫히기 직전에 해당 연결로 다시 보내질 수 있습니다. CRLF 종결자는 연결로 다시 보내지기 전에 문자열에 추가됩니다.


주 –

MMP는 PORT_ACCESS 매핑 테이블을 사용하지 않습니다. 특정 IP 주소의 SMTP 연결을 거부하기를 원하고 MMP를 사용하는 경우 TCPAccess 옵션을 사용해야 합니다. MMP를 사용하여 메일 액세스 구성를 참조하십시오. 매핑 테이블을 사용하여 SMTP 연결을 제어하려면 INTERNAL_IP 매핑 테이블을 사용합니다( 외부 사이트에 대한 SMTP 릴레이 허용 참조).


$< 플래그 다음에 선택적 문자열이 있으면 매핑 검사가 일치하는 경우 Messaging Server는 문자열을 syslog(UNIX) 또는 이벤트 로그(NT)로 보냅니다. $> 플래그 다음에 선택적 문자열이 오면 액세스가 거부된 경우 Messaging Server는 syslog(UNIX) 또는 이벤트 로그(NT)로 보냅니다. LOG_CONNECTION MTA 옵션이 비트 1로 설정되고 $N 플래그가 설정되어 연결이 거부된 경우 $T 플래그를 지정하면 “T” 항목이 연결 로그에 기록됩니다. LOG_CONNECTION MTA 옵션이 비트 4로 설정된 경우에는 사이트 제공 텍스트가 PORT_ACCESS 항목에 제공되어 “C” 연결 로그 항목에 포함될 수 있습니다. 이러한 텍스트를 지정하려면 항목의 오른쪽에 두 개의 세로 막대 문자를 넣고 그 뒤에 원하는 텍스트를 입력합니다. 표 17–3에는 사용 가능한 플래그가 나열되어 있습니다.

표 17–3 PORT_ACCESS 매핑 플래그

플래그 

설명 

$Y 

액세스를 허용합니다. 

인수가 있는 플래그, 인수 읽기 순서에 따라+ 

$< 문자열 

검사가 일치하는 경우 syslog (UNIX) 또는 이벤트 로그(NT)에 문자열을 보냅니다. 

$> 문자열 

액세스가 거부되는 경우 syslog (UNIX) 또는 이벤트 로그(NT)에 문자열을 보냅니다.  

$N 문자열 

선택적 오류 텍스트 문자열을 사용하여 액세스를 거부합니다. 

$F 문자열 

$N 문자열에 대한 동의어, 즉 선택적 오류 텍스트 문자열을 사용하여 액세스를 거부합니다.  

$T 텍스트 

LOG_CONNECTION MTA 옵션이 비트 1(값 2)로 설정되고 $N 플래그가 설정되어 연결이 거부된 경우 $T를 지정하면 “T” 항목이 연결 로그에 기록됩니다. T 로그 항목에는 전체 매핑 결과 문자열($N 및 해당 문자열)이 포함되어 있습니다.

+ 인수가 있는 여러 개의 플래그를 사용하려면 인수를 세로 막대 문자 |로 구분하고 이 테이블에 나열된 순서대로 인수를 배치합니다. 

예를 들어, 다음 매핑은 설명하는 텍스트가 없이 추출되어 거부된 특정 호스트를 제외한 단일 네트워크로부터의 SMTP 연결(포트 25, 일반 SMTP 포트)만 수락합니다.


PORT_ACCESS

  TCP|*|25|192.123.10.70|*  $N500
  TCP|*|25|192.123.10.*|*   $Y
  TCP|*|25|*|*              $N500$ Bzzzt$ thank$ you$ for$ playing.

         

PORT_ACCESS 매핑 테이블을 변경한 뒤에는 디스패처를 다시 시작해야 디스패처에 변경 내용이 적용됩니다. 컴파일된 MTA 구성을 사용하는 경우에는 먼저 구성을 다시 컴파일하여 변경 내용을 컴파일된 구성에 통합시켜야 합니다.

PORT_ACCESS 매핑 테이블은 특별히 IP 기반 거부를 수행하기 위한 것입니다. 메일 주소 수준 일반 제어의 경우 SEND_ACCESS 또는 MAIL_ACCESS 매핑 테이블이 보다 적합합니다.

MTA에 대해 지정된 IP 액세스 연결 제한

Port Access 매핑 테이블에 conn_throttle.so 공유 라이브러리를 사용하여 특정 IP 주소가 MTA에 연결되는 횟수를 제한할 수 있습니다. 특정 IP 주소로 연결을 제한하는 기능은 서비스 거부 공격에 사용되는 과도한 연결을 방지하는 데 유용합니다.

conn_throttle.so는 특정 IP 주소가 MTA에 너무 자주 연결하는 것을 제한하기 위해 PORT_ACCESS 매핑 테이블에 사용되는 공유 라이브러리입니다. 모든 구성 옵션은 다음과 같이 연결 억제 공유 라이브러리에 대한 매개 변수로 지정됩니다.

$[msg_svr_base/lib/conn_throttle.so, throttle,IP-address ,max-rate]

IP-address는 원격 시스템의 점으로 구분된 십진수 형식의 주소이며, max-rate는 이 IP 주소에 대한 최대 분당 연결 비율입니다.

루틴 이름 throttle_p를 루틴 축소 버전의 throttle 대신 사용할 수 있습니다. throttle_p는 향후 기존에 너무 많이 연결했던 연결을 거부하게 됩니다. 최대 비율이 100인데 분당 250번의 연결이 시도된 경우에는 해당 분 내에 처음 100번의 연결 시도 후 원격 사이트가 차단되며 그 다음 1분 동안에도 차단됩니다. 즉, 매 분마다 시도된 전체 연결 수에서 최대 비율을 빼서 전체 연결 수가 최대 비율보다 크면 원격 시스템이 차단됩니다.

지정된 IP 주소가 분당 최대 연결 비율을 초과하지 않으면 공유 라이브러리 호출이 실패합니다.

해당 비율을 초과하면 호출에 성공하지만 아무 것도 반환하지 않습니다. 이 작업은 다음 예와 같이 $C/$E 조합으로 수행됩니다.

PORT_ACCESS 
  TCP|*|25|*|* \
$C$[msg_svr_base/lib/conn_throttle.so,throttle,$1,10] \
$N421$ Connection$ not$ accepted$ at$ this$ time$E

여기서

$C는 다음 테이블 항목에서 시작한 매핑 프로세스를 계속하여 이 항목의 출력 문자열을 매핑 프로세스에 대한 새 입력 문자열로 사용합니다.

$[msg_svr_base/lib/conn_throttle.so,throttle,$1,10]throttle을 라이브러리 루틴, $1을 서버 IP 주소, 그리고 10을 분당 연결 임계값으로 사용하는 라이브러리 호출입니다.

$N421$ Connection$ not$ accepted$ at$ this$ time은 액세스를 거부하고 “Connection not accepted at this time”이라는 메일과 함께 421 SMTP 코드(임시 부정 완료)를 반환합니다.

$E는 이제 매핑 프로세스를 닫습니다. 이 항목의 출력 문자열을 매핑 프로세스의 최종 결과로 사용합니다.

액세스 제어가 적용되는 경우

Messaging Server는 가능한 빨리 액세스 제어 매핑을 검사합니다. 정확한 작업 수행 시기는 사용 중인 전자 메일 프로토콜에 따라 다릅니다(검사해야 하는 정보가 사용 가능한 경우).

SMTP 프로토콜의 경우 MAIL FROM: 명령에 대한 응답으로 FROM_ACCESS 거부가 수행된 후 보내는 측에서 수신자 정보나 메일 데이터를 보낼 수 있습니다. 보내는 측에서 메일 데이터를 보내기 전에 RCPT TO: 명령에 대한 응답으로 SEND_ACCESS 또는 MAIL_ACCESS 거부가 수행됩니다. SMTP 메일이 거부되면 Messaging Server는 메일 데이터를 수락하거나 볼 수 없으므로 이러한 거부 수행으로 인한 오버헤드가 최소화됩니다.

여러 개의 액세스 제어 매핑 테이블이 있으면 Messaging Server는 이들 모두를 검사합니다. 즉, FROM_ACCESS, SEND_ACCESS, ORIG_SEND_ACCESS, MAIL_ACCESSORIG_MAIL_ACCESS 매핑 테이블이 모두 영향을 받을 수 있습니다.

액세스 제어 매핑 테스트

imsimta test -rewrite 유틸리티(특히 -from, -source_channel, -sender-destination_channel 옵션과 함께 사용 시)는 액세스 제어 매핑을 테스트할 때 유용합니다. 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Referenceimsimta test를 참조하십시오. 아래 예는 샘플 SEND_ACCESS 매핑 테이블 및 그 검사 결과를 보여 줍니다.


MAPPING TABLE:

SEND_ACCESS

  tcp_local|friendly@siroe.com|l|User@sesta.com     $Y 
  tcp_local|unwelcome@varrius.com|l|User@sesta.com  $NGo$ away!

PROBE:

$ TEST/REWRITE/FROM="friendly@siroe.com" -
_$ /SOURCE=tcp_local/DESTINATION=l User@sesta.com
...
Submitted address list: 
  l
    User (SESTA.COM) *NOTIFY FAILURES* *NOTIFY DELAYS* Submitted 
notifications list:

$ TEST/REWRITE/FROM="unwelcome@varrius.com" -
_$ /SOURCE=tcp_local/DESTINATION=l User@sesta.com
...
Submitted address list: 
Address list error -- 5.7.1 Go away! User@sesta.com  

Submitted notifications list:
      

SMTP 릴레이 추가

기본적으로 Messaging Server는 SMTP 릴레이 시도를 차단하도록 구성되어 있습니다. 즉, 인증되지 않은 외부 소스의 외부 주소로의 메일 전송 시도를 거부합니다. 외부 시스템은 서버가 있는 호스트가 아닌 모든 시스템을 말합니다. 이 기본 구성은 다른 모든 시스템을 외부 시스템으로 간주하기 때문에 과도하게 SMTP 중계를 차단합니다.

Messaging Server 시스템의 SMTP 서버를 통해 외부 주소로 지정된 메일을 전송하려고 시도하는 IMAP 및 POP 클라이언트, 그리고 SMTP AUTH(SASL)를 사용하여 인증하지 않는 클라이언트의 전송 시도는 거부됩니다. 따라서 사용자 구성을 수정하여 중계를 항상 수락하는 자체 내부 시스템과 서브넷을 인식하도록 할 수 있습니다.

내부로 인식되는 시스템과 서브넷은 일반적으로 msg_svr_base/config/mappings 파일에 포함된 INTERNAL_IP 매핑 테이블을 통해 제어됩니다.

예를 들어, IP 주소가 123.45.67.89인 Messaging Server 시스템에서 기본 INTERNAL_IP 매핑 테이블은 다음과 같이 나타납니다.


INTERNAL_IP 

   $(123.45.67.89/32)   $Y
   127.0.0.1            $Y
   *   $N
      

여기서 첫 번째 항목은 $(IP-pattern/signicant-prefix-bits) 구문을 사용하여 123.45.67.89의 32비트와 완전히 일치하는 모든 IP 주소를 내부로 인식하도록 지정합니다. 두 번째 항목은 루프백 IP 주소 127.0.0.1을 내부로 인식합니다. 마지막 항목은 다른 모든 IP 주소가 내부로 인식되지 않도록 지정합니다. 모든 항목 앞에는 적어도 하나의 공백이 있어야 합니다.

마지막 $N 항목 앞에 추가 IP 주소 또는 서브넷을 지정하여 항목을 추가할 수 있습니다. 이러한 항목은 왼쪽에 IP 주소나 서브넷($(.../...구문을 사용하여 서브넷 지정)을 지정하고 오른쪽에 $Y를 지정합니다. 또는 기존 $(.../...) 항목을 수정하여 더 일반적인 서브넷을 허용할 수 있습니다.

예를 들어, 동일한 샘플 사이트의 네트워크가 클래스 C 네트워크, 즉 123.45.67.0 서브넷을 모두 소유하는 네트워크인 경우 해당 사이트에서는 주소 일치에 사용되는 비트 수를 변경하여 첫 번째 항목을 수정해야 합니다. 아래 매핑 테이블에서는 32비트를 24비트로 수정합니다. 이렇게 하면 클래스 C 네트워크의 모든 클라이언트에서 SMTP 중계 서버를 통해 메일을 중계할 수 있습니다.


INTERNAL_IP 

   $(123.45.67.89/24)   $Y
   127.0.0.1   $Y
   *   $N
      

또는 사이트가 123.45.67.80-123.45.67.99 범위 내의 IP 주소만 소유하는 경우 해당 사이트는 다음을 사용할 수 있습니다.

INTERNAL_IP 

! Match IP addresses in the range 123.45.67.80-123.45.67.95 
   $(123.45.67.80/28) $Y
! Match IP addresses in the range 123.45.67.96-123.45.67.99 
   $(123.45.67.96/30) $Y 
   127.0.0.1 $Y 
   * $N

imsimta test -match 유틸리티는 IP 주소가 특정 $(.../...) 테스트 조건에 일치하는지 여부를 검사할 때 유용하게 사용할 수 있습니다. imsimta test -mapping 유틸리티는 INTERNAL_IP 매핑 테이블이 다양한 IP 주소 입력에 대해 원하는 결과를 반환하는지 검사할 때 매우 유용합니다.

INTERNAL_IP 매핑 테이블을 수정한 뒤에는 imsimta restart 명령(컴파일된 구성을 실행하고 있지 않은 경우) 또는 imsimta cnbuild 명령 뒤에 imsimta restart smtp 명령(컴파일된 구성을 실행하는 경우)을 실행해야 변경 사항이 적용됩니다.

매핑 테이블과 일반적인 매핑 테이블 형식 및 imsimta 명령줄 유틸리티에 대한 자세한 내용은 Messaging Server Reference Manual을 참조하십시오.

외부 사이트에 대한 SMTP 릴레이 허용

위에서 설명한 것처럼 모든 내부 IP 주소를 INTERNAL_IP 매핑 테이블에 추가해야 합니다. 다른 시스템/사이트에서 SMTP 릴레이를 허용하려는 경우 가장 간단한 방법은 해당 시스템/사이트를 INTERNAL_IP 매핑 테이블에 사용자의 실제 내부 IP 주소와 함께 포함시키는 것입니다.

다른 시스템/사이트를 실제 내부 시스템/사이트로 인식시키지 않으려는 경우(예를 들어 로깅이나 다른 제어 목적을 위해 실제 내부 시스템릴레이 권한을 가진 내부가 아닌 시스템을 구분하려는 경우) 다른 방법으로 시스템을 구성할 수 있습니다.

한 가지 방법은 다른 시스템에서 보내는 메일을 받는 특별 채널을 설정하는 것입니다. 이렇게 하려면 기존 tcp_internal과 유사한 tcp_friendly 채널을 공식 호스트 이름 tcp_friendly-daemon으로 만들고 다른 시스템 IP 주소가 나열된 INTERNAL_IP 매핑 테이블과 유사한 FRIENDLY_IP 매핑 테이블을 만듭니다. 그런 후 다음과 같은 현재 다시 쓰기 규칙 바로 뒤에

! Do mapping lookup for internal IP addresses 
[]    $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

다음과 같이 다시 쓰기 규칙을 새로 추가합니다.

! Do mapping lookup for "friendly", non-internal IP addresses
[]     $E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

또 다른 방법은 위의 ORIG_SEND_ACCESS 매핑 테이블에 다음 형식의 새로운 최종 $N 항목을 추가하고

tcp_local|*@siroe.com|tcp_local|*     $Y

(여기서 siroe.com은 다른 도메인의 이름) 다음 형식의 ORIG_MAIL_ACCESS 매핑 테이블을 추가하는 것입니다.

ORIG_MAIL_ACCESS 

   TCP|*|25|$(match-siroe.com-IP-addresses)|*|SMTP|MAIL|   \
tcp_local|*@siroe.com|tcp_local|*      $Y 
   TCP|*|*|*|*|SMTP|MAIL|tcp_local|*|tcp_local|* $N

여기서 $(...) IP 주소 구문은 이전 절에서 설명한 것과 같은 구문입니다. ORIG_SEND_ACCESS 검사는 주소가 정상인 경우 지속되므로 계속 수행할 수 있으며 또한 IP 주소가 siroe.com IP 주소에 해당하는 경우에 한해 보다 엄격한 ORIG_MAIL_ACCESS 검사를 수행할 수 있습니다.

SMTP 릴레이 차단 구성

액세스 제어 매핑을 사용하여 다른 사용자가 Messaging Server 시스템을 통해 SMTP 메일을 릴레이하지 못하도록 할 수 있습니다. 예를 들어, 다른 사용자가 메일 시스템을 사용하여 대량 전자 메일을 수백 수천의 인터넷 메일함으로 릴레이하지 못하도록 할 수 있습니다.

기본적으로 Messaging Server는 로컬 POP 및 IMAP 사용자에 의한 릴레이를 포함하여 모든 SMTP 릴레이 작업을 차단합니다.

적합한 로컬 사용자에게 릴레이를 허용하면서 인증되지 않은 릴레이를 차단하려면 Messaging Server에서 이 두 클래스의 사용자를 서로 구분할 수 있도록 구성해야 합니다. 예를 들어, POP나 IMAP를 사용하는 로컬 사용자의 경우 Messaging Server가 SMTP 릴레이 역할을 수행합니다.

SMTP 릴레이를 차단하려면 다음이 가능해야 합니다.

내부 호스트 및 클라이언트에서 SMTP 릴레이를 사용하려면 “내부” IP 주소나 서브넷을 INTERNAL_IP 매핑 테이블에 추가해야 합니다.

MTA의 내부 메일과 외부 메일 구분 방법

메일 릴레이 작업을 차단하려면 MTA는 먼저 사용자 사이트에서 전송된 내부 메일과 외부 인터넷에서 전송되어 사용자 시스템을 경유하여 다시 인터넷으로 나가는 외부 메일을 구분할 수 있어야 합니다. 내부 메일은 허용하고 외부 메일은 차단하려 합니다. 인바운드 SMTP 채널(일반적으로 tcp_local 채널이며 기본적으로 설정됨)에서 switchchannel 키워드를 사용하여 구분할 수 있습니다.

switchchannel 키워드를 사용하여 SMTP 서버가 들어오는 SMTP 연결에 연관된 실제 IP 주소를 조사합니다. Messaging Server는 이 IP 주소와 다시 쓰기 규칙을 결합하여 도메인 내에서 보낸 SMTP와 도메인 외부로부터의 연결을 구분합니다. 그런 다음 이 정보는 내부 메일 트래픽과 외부 메일 트래픽을 분리하는 데 사용될 수 있습니다.

아래 설명된 MTA 구성은 기본적으로 서버가 내부 메일 트래픽과 외부 메일 트래픽을 구분할 수 있도록 설정됩니다.

위 구성 설정으로 도메인 내에서 생성된 SMTP 메일은 tcp_intranet 채널을 통해 들어옵니다. 다른 모든 SMTP 메일은 tcp_local 채널을 통해 들어옵니다. 이렇게 해당 메일이 들어오는 채널을 기준으로 내부 메일과 외부 메일이 구분됩니다.

이 작업의 작동 방식에 대해 알아보겠습니다. 여기서 핵심은 switchchannel 키워드이며,tcp_local 채널에 적용됩니다. 서버는 메일이 SMTP 서버에 들어오면 키워드를 통해 받는 연결과 연관된 소스 IP 주소를 검사합니다. 서버는 받는 연결의 리터럴 IP 주소에 대해 역방향 지정 봉투 다시 쓰기를 시도하여 연관된 채널을 찾습니다. 소스 IP 주소가 INTERNAL_IP 매핑 테이블 내의 IP 주소나 서브넷과 일치하는 경우 해당 매핑 테이블을 호출하는 다시 쓰기 규칙을 통해 해당 주소가 tcp_intranet 채널로 다시 쓰여집니다.

tcp_intranet 채널은 allowswitchchannel 키워드로 표시되기 때문에 메일은 tcp_intranet 채널로 전환되어 해당 채널로 들어갑니다. 메일이 INTERNAL_IP 매핑 테이블에 없는 IP 주소의 시스템에서 들어오는 경우 역방향 지정 봉투 다시 쓰기로 tcp_local 또는 다른 채널로 다시 씁니다. 하지만 tcp_intranet 채널로는 다시 쓰지 않으며 다른 모든 채널은 기본적으로 noswitchchannel로 표시되어 있으므로 메일은 다른 채널로 전환되지 않고 tcp_local 채널로 남아 있게 됩니다.


주 –

tcp_local” 문자열을 사용하는 모든 매핑 테이블이나 변환 파일 항목은 사용법에 따라 “tcp_*” 또는 “tcp_intranet”으로 변경해야 할 수 있습니다.


인증된 사용자의 메일 구분

사이트에는 물리적 네트워크의 일부가 아닌 “로컬” 클라이언트 사용자가 있을 수 있습니다. 이러한 사용자가 메일을 전송하면 외부 IP 주소(예: 임의의 인터넷 서비스 제공자)로부터 메일이 전송됩니다. 사용자가 SASL 인증을 수행할 수 있는 메일 클라이언트를 사용하는 경우 이러한 인증된 연결을 다른 외부 연결과 구분할 수 있습니다. 따라서 인증되지 않은 릴레이 전송 시도는 거부되는 반면 인증된 전송은 허용됩니다. 인바운드 SMTP 채널(일반적으로 tcp_local 채널)에 saslswitchchannel 키워드를 사용하여 인증된 연결과 인증되지 않은 연결을 구분할 수 있습니다.

saslswitchchannel 키워드는 전환할 채널을 지정하는 인수를 취합니다. SMTP 보낸 사람이 인증에 성공하면 해당 전송 메일은 지정된 전환 대상 채널에서 오는 것으로 간주됩니다.

Procedure인증된 전송 구분을 추가하는 방법

단계
  1. 구성 파일에 고유 이름을 가진 새 TCP/IP 채널 정의를 추가합니다. 예를 들면 다음과 같습니다.

    tcp_auth smtp single_sys mx mustsaslserver noswitchchannel TCP-INTERNAL

    이 채널은 정규 채널 전환을 허용하지 않아야 합니다(즉, 이전 기본 행에서 명시적 또는 암시적으로 noswitchchannel이 있어야 함). 이 채널에는 mustsaslserver가 있어야 합니다.

  2. 다음 예에 표시된 대로 maysaslserversaslswitchchannel tcp_auth를 추가하여 tcp_local 채널을 수정합니다.


    tcp_local smtp mx single_sys maysaslserver saslswitchchannel \
    tcp_auth switchchannel
    |TCP-DAEMON

    이 구성을 사용하면 로컬 비밀번호로 인증할 수 있는 사용자가 보낸 SMTP 메일이 tcp_auth 채널에 들어갈 수 있습니다. 내부 호스트에서 보낸 인증되지 않은 SMTP 메일은 여전히 tcp_internal 채널로 들어옵니다. 다른 모든 SMTP 메일은 tcp_local로 들어옵니다.

메일 릴레이 금지

이 예에서는인증되지 않은 사용자가 시스템을 통해 SMTP 메일을 릴레이하지 못하도록 하는 것을 설명합니다. 우선 로컬 사용자는 SMTP 메일을 릴레이할 수 있어야 합니다. 예를 들어, POP 및 IMAP 사용자는 Messaging Server를 사용하여 메일을 보냅니다. 로컬 사용자는 물리적으로 메일이 내부 IP 주소에서 들어오는 로컬이거나, 물리적으로는 원격이지만 로컬 사용자로 인증이 가능한 사용자일 수 있습니다.

인터넷 상에 있는 임의의 사용자가 해당 서버를 릴레이로 사용하지 못하게 하려 합니다. 다음 절에서 설명하는 구성을 사용하면 이러한 사용자 클래스를 구분하고 올바른 클래스를 차단할 수 있습니다. 특히 tcp_local 채널을 통해 들어오고 같은 채널을 통해 나가는 메일을 차단하려 합니다. 이를 위해 ORIG_SEND_ACCESS 매핑 테이블이 사용됩니다.

ORIG_SEND_ACCESS 매핑 테이블을 사용하여 소스 채널과 대상 채널을 기반으로 트래픽을 차단할 수 있습니다. 이 경우 tcp_local 채널을 통해 송수신되는 트래픽을 차단해야 합니다. 이 기능은 다음 ORIG_SEND_ACCESS 매핑 테이블로 구현됩니다.

ORIG_SEND_ACCESS

   tcp_local|*|tcp_local|*        $NRelaying$ not$ permitted

이 예에서 해당 항목은 메일이 tcp_local 채널에 들어가서 바로 해당 채널로 다시 나올 수 없도록 지정합니다. 즉, 이 항목은 외부 메일이 SMTP 서버로 들어와서 곧바로 인터넷으로 릴레이되는 것을 방지합니다.

ims-ms 채널과 일치하는 주소(하지만 별칭이나 메일링 목록 정의를 통해 다시 외부 주소로 확장될 수 있는 주소)를 차단할 수 있도록 SEND_ACCESS 매핑 테이블 대신 ORIG_SEND_ACCESS 매핑 테이블이 사용됩니다. SEND_ACCESS 매핑 테이블을 사용할 때는 외부 사용자가 다시 외부 사용자로 확장되는 메일링 목록을 보내거나 메일을 다시 외부 주소로 전달하는 사용자에게 보낼 수 있도록 하려면 길이를 늘여야 합니다.

SMTP 릴레이 차단에 RBL 검사를 포함한 DNS 조회 사용

Messaging Server에는 유효한 DNS 이름을 가진 주소에서 전송된 메일만 전달되도록 하는 여러 방법이 있습니다. 가장 간단한 방법은 tcp_local 채널에 mailfromdnsverify 채널 키워드를 지정하는 것입니다.

Messaging Server는 ORIG_MAIL_ACCESS에서 다음 규칙을 사용하여 유효한 DNS 이름을 가진 주소에서 전송된 메일만 전달되도록 하는 dns_verify 프로그램도 제공합니다.

ORIG_MAIL_ACCESS

  TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*  \
$[msg_svr_base/lib/dns_verify.so,  \
dns_verify,$6|$$y|$$NInvalid$ host:$ $$6$ -$ %e]

위 예에서 줄 바꿈은 이러한 매핑 항목에서 구문적으로 매우 중요합니다. 다음 행으로 진행하려면 백슬래시 문자를 사용해야 합니다.

또한 dns_verify 이미지를 사용하여 받는 연결을 RBL(Realtime Blackhole List), MAPS(Mail Abuse Prevention System, DUL(Dial-up User List) 또는 ORBS(Open Relay Behavior-modification System) 목록 등에 대해 검사하여 UBE로부터 보호할 수 있습니다. 새 mailfromdnsverify 키워드와 마찬가지로 dns_verify 콜아웃을 수행하는 대신 “보다 간단한 구성” 방법으로 이러한 검사를 수행할 수도 있습니다. 보다 간단한 방법은 dispatcher.cnf 파일에 DNS_VERIFY_DOMAIN 옵션을 사용하는 것입니다. 예를 들어, [SERVICE=SMTP] 섹션에서 검사하려는 다양한 목록에 대한 옵션의 인스턴스를 설정합니다.


[SERVICE=SMTP]
PORT=25
! ...rest of normal options...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com!
...etc...

이 경우 메일은 SMTP 수준에서 거부됩니다. 즉 메일은 SMTP 대화 도중 거부되므로 MTA로 전송되지 않습니다. 이 방법의 단점은 내부 사용자가 보낸 메일을 포함하여 모든 받는 SMTP 메일을 검사한다는 것입니다. 따라서 효율성이 떨어지며 인터넷 연결이 중지되면 문제가 발생할 수 있습니다. 그 대안은 PORT_ACCESS 매핑 테이블 또는 ORIG_MAIL_ACCESS 매핑 테이블로부터 dns_verify를 호출하는 것입니다. PORT_ACCESS 매핑 테이블에는 로컬 내부 IP 주소나 메일 전송자를 검사하지 않는 초기 항목과 다른 모든 사용자에 대해 원하는 검사를 수행하는 후기 항목을 지정할 수 있습니다. 또는 ORIG_MAIL_ACCESS 매핑 테이블에서 tcp_local 채널로 받는 메일에만 검사를 적용하려는 경우에는 내부 시스템/클라이언트로부터 받는 메일에 대해 해당 검사를 건너뛸 수 있습니다. dns_verify를 가리키는 항목을 사용하는 예는 다음과 같습니다.

PORT_ACCESS

! Allow internal connections in unconditionally 
  *|*|*|*|*  $C$|INTERNAL_IP;$3|$Y$E
! Check other connections against RBL list
   TCP|*|25|*|*  \
$C$[msg_svr_base/lib/dns_verify.so,\
dns_verify_domain_port,$1,rbl.maps.vix.com.]EXTERNAL$E


ORIG_MAIL_ACCESS 

  TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|*  \
$C$[msg_svr_base/lib/dns_verify.so,\
dns_verify_domain,$1,rbl.maps.vix.com.]$E

DNS 기반 데이터베이스 지원

dns_verify 프로그램은 원치 않는 대량 전자 메일을 보낼 수 있는 받는 SMTP 연결을 확인하는 데 사용되는 DNS 기반 데이터베이스를 지원합니다. 공개적으로 사용 가능한 DNS 데이터베이스 중 일부는 일반적으로 이러한 용도로 사용되는 TXT 레코드를 포함하지 않을 수 있습니다. 대신 A 레코드만 포함합니다.

일반 설정에서 특정 IP 주소에 대한 DNS의 TXT 레코드에는 메일을 거부할 때 SMTP 클라이언트로 반환하기에 적합한 오류 메시지가 포함되어 있습니다. 하지만 TXT 레코드가 없고 A 레코드가 있는 경우 Messaging Server 5.2 이전의 dns_verify 버전에서는 “No error text available이라는 메시지를 반환했습니다. ”

이제 dns_verify에서는 사용 가능한 TXT 레코드가 없는 경우에 사용되는 기본 텍스트를 지정하는 옵션을 제공합니다. 예를 들어, 다음 PORT_ACCESS 매핑 테이블에서는 이 옵션을 사용하는 방법을 보여 줍니다.

PORT_ACCESS 

   *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E  \
   TCP|*|25|*|*   \
$C$[<msg_svr_base/lib/dns_verify.so \
,dns_verify_domain_port,$1,dnsblock.siroe.com,Your$ host$ ($1)$ \
found$ on$ dnsblock$ list]$E 
    * $YEXTERNAL

이 예에서 원격 시스템이 dnsblock.siroe.com 도메인의 쿼리에 있지만 TXT 레코드를 사용할 수 없는 경우에는 “Your host a.b.c.d found on dnsblock list.

많은 수의 액세스 항목 처리

매핑 테이블에서 많은 수의 항목을 사용하는 사이트는 특정 조회에 대해 일반 데이터베이스를 호출하는 몇 개의 일반적인 와일드카드 항목이 매핑 테이블에 포함되도록 구성해야 합니다. 매핑 테이블에 많은 수의 항목이 직접 존재하는 것보다 특정 조회에 대해 일반 데이터베이스를 호출하는 매핑 테이블 항목이 몇 개 있는 것이 더 효율적입니다.

특별한 경우 인터넷 전자 메일을 보내고 받을 수 있는 사용자별로 제어하려는 사이트가 있을 수 있습니다. 이러한 제어는 ORIG_SEND_ACCESS 등의 액세스 매핑 테이블을 사용하여 편리하게 구현될 수 있습니다. 이 때 대량의 특정 정보(예: 특정 주소)를 일반 데이터베이스에 저장하고 매핑 테이블 항목을 일반 데이터베이스로 적절하게 호출할 수 있도록 하면 효율성과 성능이 크게 향상될 수 있습니다.

예를 들어, 다음 ORIG_SEND_ACCESS 매핑 테이블을 살펴보십시오.


ORIG_SEND_ACCESS
 
! Users allowed to send to Internet
!
  *|adam@siroe.com|tcp_local|*    $Y
  *|betty@siroe.com|tcp_local|*   $Y
! ...etc...
!
! Users not allowed to send to Internet
!
  *|norman@siroe.com|tcp_local|*  $NInternet$ access$ not$ permitted
  *|opal@siroe.com|tcp_local|*    $NInternet$ access$ not$ permitted
! ...etc...
!
! Users allowed to receive from the Internet
!
  tcp_*|*|*|adam@siroe.com        $Y
  tcp_*|*|*|betty@siroe.com       $Y
! ...etc...
!
! Users not allowed to receive from the Internet
!
  tcp_*|*|*|norman@siroe.com      $NInternet$ e-mail$ not$ accepted
  tcp_*|*|*|opal@siroe.com        $NInternet$ e-mail$ not$ accepted
! ...etc...
      

테이블에 각 사용자가 개별적으로 입력된 매핑 테이블을 사용하는 것보다 더 효율적인 설정(수만 명의 사용자 항목이 있는 경우 특히 더 효율적임)이 아래 예에 나와 있습니다. 이 예에서는 일반 데이터베이스의 샘플 소스 텍스트 파일과 샘플 ORIG_SEND_ACCESS 매핑 테이블을 볼 수 있습니다. 이 소스 파일을 데이터베이스 형식으로 컴파일하려면 imsimta crdb 명령을 실행합니다.

% imsimta crdb input-file-spec output-database-spec

imsimta crdb 유틸리티에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Referenceimsimta crdb를 참조하십시오.


DATABASE ENTRIES

SEND|adam@domain.com    $Y
SEND|betty@domain.com   $Y
! ...etc...
SEND|norman@domain.com  $NInternet$ access$ not$ permitted
SEND|opal@domain.com    $NInternet$ access$ not$ permitted
! ...etc...
RECV|adam@domain.com    $Y
RECV|betty@domain.com   $Y
! ...etc...
RECV|norman@domain.com  $NInternet$ e-mail$ not$ accepted
RECV|opal@domain.com    $NInternet$ e-mail$ not$ accepted


MAPPING TABLE

ORIG_SEND_ACCESS

! Check if may send to Internet
!
  *|*|*|tcp_local       $C${SEND|$1}$E
!
! Check if may receive from Internet
!
  tcp_*|*|*|*           $C${RECV|$3}$E
      

이 예에서 일반 데이터베이스 왼쪽에(그리고 이에 따라 매핑 테이블에 의해 생성된 일반 데이터베이스 검사에) 임의 문자열 SEND| 및 RECV|를 사용하면 두 가지 종류의 검사를 구분할 수 있습니다. 표시된 대로 일반 데이터베이스 검사 앞뒤에 $C와 $E 플래그를 붙이는 것은 일반 데이터베이스에 대한 일반적인 매핑 테이블 호출입니다.

위의 예에서는 일반 데이터베이스 항목에 대한 간단한 매핑 테이블 검사를 보여 줍니다. 보다 복잡한 검사를 수행하는 매핑 테이블도 일반 테이블을 사용하여 효율성을 높일 수 있습니다.

2부. 메일함 필터

메일함 필터(Sieve 필터라고도 함)는 메일 헤더에 지정된 문자열을 포함한 메일을 필터링 하고 이러한 메일 메시지에 지정한 작업을 적용합니다. 관리자는 채널이나 MTA를 통해 사용자에게 가는 메일 스트림을 필터링합니다. Messaging Server 필터는 서버에 저장되며 서버에 의해 평가됩니다. 따라서 이를 서버측 규칙(SSR)이라고도 합니다.

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

Sieve 필터 지원

Messaging Server 필터는 Sieve 필터링 언어(Draft 9 of the Sieve Internet Draft)를 기반으로 합니다. Sieve 구문과 의미에 대한 자세한 내용은 RFC3028을 참조하십시오. 또한, Messaging Server는 다음의 Sieve 확장도 지원합니다.

Sieve 필터링 개요

Sieve 필터는 메일 헤더에 있는 문자열에 따라 메일에 적용되는 하나 이상의 조건적 작업으로 구성됩니다. 관리자는 채널 수준 필터와 MTA 차원 필터를 만들어서 원하지 않는 메일의 전달을 방지할 수 있습니다. 사용자는 Messenger Express를 사용하여 자신의 메일함에 사용자별 필터를 만들 수 있습니다. 구체적인 지침은 Messenger Express 온라인 도움말을 참조하십시오.

서버는 다음 우선 순위에 따라 필터를 적용합니다.

  1. 사용자 수준 필터

    개인 메일함이 메일을 명시적으로 수락하거나 거부하면 해당 메일에 대한 필터 처리가 종료됩니다. 하지만 수신자에게 메일함 필터가 없거나 사용자의 메일함 필터가 해당 메일에 명시적으로 적용되지 않는 경우에는 Messaging Server가 채널 수준 필터를 적용합니다. 사용자별 필터가 설정됩니다.

  2. 채널 수준 필터

    채널 수준 필터가 메일을 명시적으로 수락하거나 거부하면 해당 메일에 대한 필터 처리가 종료됩니다. 그렇지 않으면 Messaging Server가 MTA 차원 필터(있는 경우)를 적용합니다.

  3. MTA 차원 필터

기본적으로 각 사용자에게는 메일함 필터가 없습니다. 사용자가 Messenger Express 인터페이스를 사용하여 하나 이상의 필터를 만들면 해당 필터가 디렉토리에 저장되어 디렉토리 동기화 프로세스 도중 MTA에 의해 검색됩니다.

사용자 수준 필터 만들기

사용자별 메일 필터는 특정 사용자의 메일함을 대상으로 하는 메일에 적용됩니다. 사용자별 메일 필터는 Messenger Express를 통해서만 만들 수 있습니다.

채널 수준 필터 만들기

채널 수준 필터는 채널에 대기된 각 메일에 적용됩니다. 이러한 필터의 일반적 용도는 특정 채널을 통과하는 메일을 차단하는 것입니다.

표 17–4 filter 채널 키워드 URL 패턴 대체 태그(대소문자 무시)

태그 

의미 

그룹 확장을 수행합니다. 

** 

속성 mailForwardingAddress를 확장합니다. 여러 전달 주소를 생성할 수 있는 값이 여러 개인 속성일 수 있습니다.

$$ 

$ 문자 대체입니다. 

$\ 

후속 텍스트를 소문자로 바꿉니다. 

$^ 

후속 텍스트를 대문자로 바꿉니다. 

$_ 

후속 텍스트에 대해 대소문자 변환을 수행하지 않습니다. 

$~ 

주소의 로컬 부분과 연관된 홈 디렉토리에 대한 파일 경로를 대체합니다. 

$1S 

$S와 비슷하지만 하위 주소를 사용할 수 없는 경우 아무 것도 삽입하지 않습니다.

$2S 

$S와 비슷하지만 하위 주소를 사용할 수 없는 경우 아무 것도 삽입하지 않으며 선행 문자를 삭제합니다.

$3S 

$S와 비슷하지만 하위 주소를 사용할 수 없는 경우 아무 것도 삽입하지 않으며 후행 문자를 무시합니다.

$A 

주소 local-part@ host.domain을 대체합니다. 

$D 

host.domain을 대체합니다. 

$E 

두 번째 예비 속성 값, LDAP_SPARE_1을 삽입합니다.

$F 

전달 파일의 이름(mailDeliveryFileURL 속성)을 삽입합니다.

$G 

두 번째 예비 속성 값, LDAP_SPARE_2를 삽입합니다.

$H 

호스트를 대체합니다. 

$I 

호스트된 도메인(domainUidSeparator에 의해 지정된 구분자의 오른쪽에 있는 UID 일부)을 삽입합니다. 호스트된 도메인을 사용할 수 없는 경우 실패합니다.

$1I 

$I와 비슷하지만 호스트된 도메인을 사용할 수 없는 경우 아무 것도 삽입하지 않습니다.

$2I 

$I와 비슷하지만 호스트된 도메인을 사용할 수 없는 경우 아무 것도 삽입하지 않고 선행 문자를 삭제합니다.

$3I 

$I와 비슷하지만 호스트된 도메인을 사용할 수 없는 경우 아무 것도 삽입하지 않고 후행 문자를 무시합니다.

$L 

로컬 부분을 대체합니다. 

$M 

호스트된 도메인을 제거하고 UID를 삽입합니다. 

$P 

메소드 이름(mailProgramDeliveryInfo 속성)을 삽입합니다.

$S 

현재 주소와 연관된 하위 주소를 삽입합니다. 하위 주소는 하위 주소 구분자 뒤에 있는 원래 주소의 일부 사용자 부분입니다. 여기서 구분자는 일반적으로 +이지만 MTA 옵션 SUBADDRESS_CHAR로 지정할 수 있습니다. 하위 주소를 지정하지 않으면 실패합니다.

$U 

현재 주소의 메일함 부분을 삽입합니다. 이것은 @ 기호 왼쪽에 있는 주소 전체이거나 하위 주소 구분자 + 앞에 있는 주소의 왼쪽 부분입니다. 

Procedure채널 수준 필터 만들기

단계
  1. Sieve를 사용하여 필터를 작성합니다.

  2. 필터를 다음 디렉토리에 있는 파일에 저장합니다.

    ../config/file.filter

    이 파일은 세계 공용이어야 하며 MTA의 uid가 소유해야 합니다.

  3. 채널 구성에 다음을 포함합니다.

    destinationfilter file:IMTA_TABLE:file .filter

  4. 구성을 다시 컴파일하고 디스패처를 다시 시작합니다.

    필터 파일의 변경 내용은 다시 컴파일하거나 디스패처를 다시 시작하지 않아도 적용됩니다.

    destinationfilter 채널 키워드를 통해 해당 채널의 대기열에 포함된 메일에 대한 메일 필터링을 사용할 수 있습니다. sourcefilter 채널 키워드를 통해 채널에 의해(로부터) 대기된 메일에 대한 메일 필터링을 사용할 수 있습니다. 이러한 키워드에는 채널과 연관된 해당 채널 필터 파일에 대한 경로를 지정하는 하나의 필수 매개 변수가 있습니다.

    destinationfilter 채널 키워드 구문은 다음과 같습니다.


    destinationfilter URL-pattern
    

    The syntax for the sourcefilter channel keyword is:


    sourcefilter 
    URL-pattern
    

    where URL-pattern is a URL specifying the path to the filter file for the channel in questionIn the following example, channel-name is the name of the channel.


    destinationfilter file:///usr/tmp/filters/channel-name.filter

    filter 채널 키워드를 통해 해당 채널에 대한 메일 필터링을 사용할 수 있습니다. 키워드에는 채널을 통해 메일을 받는 각 봉투 수신자와 연관된 필터 파일의 경로를 지정하는 하나의 필수 매개 변수가 있습니다.

    filter 채널 키워드의 구문은 다음과 같습니다.


    filter URL-pattern
    

    URL-pattern은 특별한 대체 시퀀스를 처리한 후 경로를 특정 수신 주소에 대한 필터 파일로 지정하는 URL입니다. URL-pattern은 특별 대체 시퀀스 발생 시 이를 포함할 수 있으며, 이 시퀀스는 수신 주소(해당 local-part@host.domain)에서 추출된 문자열로 대체될 수 있습니다. 이러한 대체 시퀀스는 표 17–4에 나와 있습니다.

    fileinto 키워드는 메일함 필터 fileinto 연산자가 적용되었을 때 주소를 변경하는 방법을 지정합니다. 다음 예에서는 폴더 이름이 다음과 같이 원래 있던 하위 주소를 대체하면서 원래 주소의 하위 주소로 삽입되어야 한다는 것을 지정합니다.


    fileinto $U+$S@$D

MTA 차원 필터 만들기

MTA 차원 필터는 MTA에 대해 대기된 모든 메일에 적용됩니다. 이 필터의 일반적 용도는 메일의 대상에 관계 없이 원하지 않는 대량 전자 메일이나 기타 원하지 않는 메일을 차단하는 것입니다. MTA 필터를 만들려면 다음을 수행합니다.

ProcedureMTA 차원 필터 만들기

단계
  1. Sieve를 사용하여 필터를 작성합니다.

  2. 다음 파일에 해당 필터를 저장합니다.

    ../imta/config/imta.filter

    이 필터는 모두가 읽을 수 있어야 하며이 파일이 있으면 자동으로 사용됩니다.

  3. 구성을 다시 컴파일하고 디스패처를 다시 시작합니다.

    컴파일된 구성을 사용하면 MTA 차원 필터 파일은 컴파일된 구성에 통합됩니다.

제거된 메일을 FILTER_DISCARD 채널 외부로 라우팅

기본적으로 메일함 필터를 통해 제거된 메일은 즉시 시스템에서 제거(삭제)됩니다. 하지만 사용자가 처음 메일함 필터를 설정할 때나(또는 실수로) 디버깅을 위해 삭제 작업이 일정 시간 동안 지연되도록 할 수 있습니다.

메일함 필터에 의해 제거된 메일을 시스템에 일시 보관한 후 나중에 삭제하려면 먼저 다음 예에 표시된 대로 삭제할 때까지 메일을 보관할 기간(일반적으로 일 수)을 지정하는 notices 채널 키워드와 함께 filter_discard 채널을 MTA 구성에 추가합니다.

filter_discard notices 7
FILTER-DISCARD

그런 다음 MTA 옵션 파일에서 FILTER_DISCARD=2 옵션을 설정합니다. filter_discard 대기열에 있는 메일은 사용자의 개인 휴지통 폴더의 확장된 범위에 들어 있는 것으로 간주해야 합니다. 따라서 filter_discard 대기열에 있는 메일에 대한 경고 메일은 보내지지 않으며 바운스 또는 반환 요청 시에도 해당 보낸 사람에게 반환되지 않습니다. 이러한 메일에 대해 수행 가능한 유일한 작업은 최종 알림 값이 만료되거나 imsimta return 등의 유틸리티를 사용하여 수동 바운스가 요청된 경우 해당 메일을 영구적으로 삭제하는 것입니다.

Messaging Server 6 2004Q2 이전에는 jettison Sieve 작업에서 filter_discard 채널 사용을 FILTER_DISCARD MTA 옵션으로 제어했습니다. 이제는 FILTER_DISCARD 설정에서 기본값을 가져오는 FILTER_JETTISON 옵션으로 제어합니다. FILTER_DISCARD의 기본값은 1입니다(discard를 bitbucket 채널로 전달).

사용자 수준 필터 디버그

사용자가 Sieve 필터가 제대로 작동하지 않는다고 불평할 경우 여러 단계를 수행하여 필터를 디버깅할 수 있습니다. 여기에서 이러한 단계에 대해 설명합니다.

Procedure사용자 수준 필터 디버그

단계
  1. fileinto 필터링이 작동하려면 imta.cnf 파일에서 ims-ms 채널이 다음과 같이 표시되어 있어야 합니다.

    fileinto $u+$s@$d

  2. 사용자의 LDAP 항목에서 사용자 수준 필터를 가져옵니다.

    사용자 수준 필터는 MailSieveRuleSource 속성 아래의 LDAP 항목에 저장됩니다. ldapsearch 명령을 사용하여 검색하려는 경우 이러한 필터가 base64 인코딩되어 있으므로 -Bo 스위치를 사용하여 출력을 디코딩해야 합니다.


    ./ldapsearch -D "cn=directory manager" -w password -b 
    "o=alcatraz.sesta.com,o=isp" -Bo uid=test

    또한 아래 설명된 imsimta test -rewrite 명령을 사용하면 디코딩이 자동으로 수행됩니다.

  3. 사용자 필터가 MTA에 표시되는지 확인합니다.

    다음 명령을 실행합니다.

    # imsimta test -rewrite -filter -debug user@sesta.com

    이렇게 하면 앞 단계에서 검색한 사용자의 sieve 필터가 출력되어야 합니다. 필터가 표시되지 않으면 LDAP 항목이 필터를 반환하지 않는 이유를 찾아야 합니다. imsimta test -rewrite 출력에 필터가 표시되면 MTA가 사용자의 필터를 인식하는 것입니다. 다음 단계에서는 imsimta test -expression 명령을 사용하여 필터 해석을 테스트합니다.

  4. imsimta test -exp를 사용하여 사용자 필터를 디버깅합니다. 다음 정보가 필요합니다.

    1. mailSieveRuleSource 속성에 있는 사용자의 Sieve 언어 문. 위 단계를 참조하십시오.

    2. 필터를 트리거한 것으로 여겨지는 rfc2822 메일

    3. 필터가 메일에 대해 수행할 것으로 예상되는 작업에 대한 설명

  5. 사용자의 mailSieveRuleSource: values를 기반으로 Sieve 언어 문을 포함하는 텍스트 파일(예: temp.filter)을 만듭니다. 예:

    require "fileinto";
    if anyof(header :contains
    ["To","Cc","Bcc","Resent-to","Resent-cc", 
       "Resent-bcc"] "commsqa"){ 
       fileinto "QMSG";
    }

    예상 결과: commsqa가 이 메일의 수신자일 경우 메일을 QMSG라는 폴더에 정리합니다.

  6. 사용자가 제공한 rfc2822 메일 파일의 내용을 포함하는 test.msg라는 텍스트 파일을 만듭니다.

    사용자 메일 저장소 영역의 .msg 파일을 사용하거나 사용자가 제공한 rfc2822 메일 파일의 내용을 포함하는 test_rfc2822.msg라는 텍스트 파일을 만들 수 있습니다.

  7. imsimta test -exp 명령을 사용합니다.


    # imsimta test -exp -mm -block -input=temp.filter -message=test_rfc2822.msg
    
  8. 출력을 검사합니다.

    imsimta test -exp 명령의 마지막 줄은 Sieve 해석의 결과를 표시합니다. 이 결과는 다음과 같습니다.


    Sieve Result: [] 
    or this: 
    Sieve Result: [action]
    

    여기서 action은 이 메일에서 Sieve 필터를 적용한 결과로 수행되는 작업입니다.

    필터 기준이 일치하면 몇 가지 작업이 결과로 표시됩니다. 필터 기준이 일치하지 않으면 빈 Sieve 결과가 표시되며 Sieve 필터에 논리적 오류가 있거나 .msg 파일에 일치하는 정보가 포함되지 않은 것입니다. 다른 오류가 발생할 경우에는 Sieve 스크립트에 구문 오류가 있는 것이므로 이를 디버깅해야 합니다.

    출력에 대한 자세한 내용은 imsimta test -exp 출력을 참조하십시오.

  9. 필터 문이 유효하고 결과가 올바를 경우 다음 단계는 tcp_local_slave.log 디버그 로그 파일을 검사하는 것입니다.

    테스트하는 메일 파일과 전송되는 메일 파일이 다를 수 있습니다. 무엇이 수신되는지 확인하는 방법은 tcp_local_slave.log 파일을 검사하는 것뿐입니다. 이 로그에는 MTA로 보내는 메일과 이 메일에 필터를 적용하는 방법이 표시되어 있습니다.

    tcp_local_slave.log 디버그 파일을 가져오는 방법은 디버깅 키워드slave_debug 키워드를 참조하십시오.

imsimta test -exp 출력

imsimta test -exp의 전체 명령은 다음과 같습니다.

# imsimta test -exp -mm -block -input=temp.filter -message=rfc2822.msg

출력 예는 다음과 같습니다.


예 17–4 imsimta test -exp 출력


# imsimta test -exp -mm -block -input tmp.filter -message=rfc2822.msg
Expression: if header :contains ["to"] ["pamw"]       (1)
Expression: {
Expression: redirect "usr3@sesta.com";
Expression: keep;
Expression: }
Expression:
Expression: Dump: header:2000114;0  3  1  :contains  1  "to"  1
"pamw"  if  8  ;
Dump: redirect:2000121;0  1  1  "usr3@sesta.com"  ;  keep:2000117;0 (2)
Dump: 0
Result: 0
Filter result: [ redirect "usr3@sesta.com" keep ]    (3)
            

1) Expression: 출력 행은 tmp.filter 텍스트 파일에서 읽고 구문 분석될 필터를 표시합니다. 이러한 행은 스크립트를 디버깅하는 데 그다지 유용하지 않습니다.

2) Dump: 출력 행은 Sieve 문을 해석하는 컴퓨터의 결과입니다. 오류가 표시되지 않아야 하며 출력이 입력과 일치하는 것으로 보여야 합니다. 예를 들어, 이 덤프에서 필터 파일 redirect "usr3@sesta.com";의 행과 같은 단어 redirect, usr3@sesta.com을 표시해야 합니다.

일치하는 텍스트가 표시되지 않은 경우에는 신경을 써야 합니다. 그렇지 않은 경우에는 스크립트를 디버깅하는 데 그다지 유용하지 않습니다.

3) 출력의 맨 아래에 Filter result: 문이 나타납니다. 앞에서 언급한 것처럼 다음과 같은 두 가지 결과가 가능합니다.

Sieve Result: [] 또는Sieve Result: [ action]

여기서 action은 Sieve 스크립트가 수행하는 작업입니다. 경우에 따라서는 빈 결과를 예상할 수도 있습니다. 예를 들어, discard 필터의 경우에는 테스트하는 모든 .msg 파일을 항상 삭제하지 않는지 테스트해야 합니다. 예를 들어 대괄호 사이에 작업이 있는 경우

Filter result: [ fileinto "QMSG" keep]

rfc2822.msg 파일의 텍스트가 필터 기준과 일치했다는 것을 의미합니다. 이 특수한 예에서 필터는 메일을 QMSG 폴더에 파일로 저장하고 복사본을 받은 메일함에 보관합니다. 이 경우의 결과 작업은 fileintokeep입니다.

필터를 테스트할 때 두 결과 모두에 대해 여러 .msg 파일을 테스트해야 합니다. 필터와 일치하는 메일이 필터링되는지, 일치시키지 않으려는 메일이 필터링되지 않는지 항상 테스트해야 합니다.

와일드카드 일치의 경우에는 :contains가 아니라 :matches 테스트를 사용해야 한다는 것에 주의합니다. 예를 들어, from=*@sesta.com을 일치시키려면 :matches를 사용해야 합니다. 그렇지 않으면 테스트 조건을 전혀 만족하지 않으므로 테스트가 실패합니다.

imsimta test -exp 구문

imsimta test -exp는 지정된 RFC2822 메일에 대해 Sieve 언어 문을 테스트하고 필터 결과를 표준 출력으로 보냅니다.

구문은 다음과 같습니다.

imsimta test -exp -mm -block -input=Sieve_language_scriptfile -message=rfc2822_message_file

여기서

-block은 전체 입력을 단일 Sieve 스크립트로 처리합니다. 기본값은 각 행을 별개의 스크립트로 처리하고 별개로 평가하는 것입니다. Sieve는 파일의 끝에 도달한 경우에만 평가됩니다.

-input=Sieve_file은 Sieve 스크립트를 포함하는 파일입니다. 기본값은 stdin에서 테스트 스크립트 행이나 스크립트 블록을 읽는 것입니다.

-message=message_file은 Sieve 스크립트를 테스트할 RFC 2822 메일을 포함하는 텍스트 파일입니다. 이 파일은 반드시 RFC 2822 메일이어야 하며 대기열 파일이 될 수 없습니다(zz*.00 파일이 아님).

이 명령은 활성화될 경우 스크립트 정보를 읽어 테스트 메일의 컨텍스트에서 평가한 다음 결과를 기록합니다. 결과에는 스크립트의 최종 문을 평가한 결과뿐만 아니라 수행되는 작업도 표시됩니다.

유용한 추가 한정자는 다음과 같습니다.

-from=address는 봉투 테스트에 사용할 봉투의 from: 주소를 지정합니다. 기본값은 RETURN_ADDRESS MTA 옵션에 지정된 값을 사용하는 것입니다.

-output=file은 결과를 file에 기록합니다. 기본값은 스크립트 평가 결과를 stdout에 기록하는 것입니다.