12장 채널 정의 구성

이 장에서는 MTA 구성 파일 imta.cnf에서 채널 키워드 정의를 사용하는 방법에 대해 설명합니다. 이 장을 읽기 전에 10 장, MTA 서비스 및 구성 정보, 8.5.3 채널 정의 및 10.2 MTA 구성 파일을 읽어 보십시오. 이 장은 다음 내용으로 구성되어 있습니다.

• 12.1 채널 기본값 구성

• 12.2 채널 키워드(알파벳순)

• 12.3 채널 키워드 범주화(기능별)

• 12.4 SMTP 채널 구성

• 12.5 메시지 처리 및 전달 구성

• 12.6 주소 처리 구성

• 12.7 헤더 처리 구성

• 12.8 첨부 파일 및 MIME 처리

• 12.9 메시지, 할당량, 수신자 및 인증 시도의 제한

• 12.10 MTA 대기열에서 파일 만들기

• 12.11 로깅 및 디버깅 구성

• 12.12 기타 키워드

imta.cnf에서 채널 정의를 변경하는 경우 imsimta restart 명령을 사용하여 시작할 때 한 번만 구성 데이터를 로드하는 프로그램 또는 채널(예: SMTP 서버)을 다시 시작해야 합니다. 컴파일된 구성을 사용하는 경우 재컴파일을 수행한 다음 다시 시작해야 합니다. 구성 정보 컴파일과 프로그램 시작에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

12.1 채널 기본값 구성

많은 구성은 모든 채널 또는 거의 모든 채널에서 다양한 채널 키워드 반복을 포함합니다. 그러한 구성의 유지 관리는 귀찮고 오류가 발생하기 쉽습니다. 일부 구성을 단순화하기 위해 다양한 채널의 기본값으로 사용할 키워드를 지정할 수 있습니다.

예를 들어, 구성 파일의 다음 행은 해당 행 다음에 있는 모든 채널 블록이 해당 행에 지정된 키워드를 상속함을 나타냅니다.

defaults keyword1 keyword2 keyword3 ...

defaults 행은 실제로 채널을 지정하지 않은 채 키워드 기본값을 변경하는 특수 채널 블록으로 간주할 수 있습니다. 또한, defaults 행에는 추가 채널 블록 정보 행이 필요하지 않습니다(무시하도록 지정된 경우).

지정 가능한 defaults 행 수에 대한 제한이 없습니다. 즉, 여러 기본값 행의 효과가 최근에 발생한 앞 행(위에서 아래로 읽음)에 누적됩니다.

구성 파일의 특정 지점(예: 외부 파일에 있는 채널 블록의 독립형 섹션의 시작 부분)에서 시작하여 defaults 행의 효과를 무조건적으로 제거하는 것이 좋을 수도 있습니다. nodefaults 행이 이러한 목적으로 제공됩니다. 예를 들어, 구성 파일에 다음 행을 삽입하면 이전의 기본값 채널에서 지정된 모든 설정이 무효화되고 구성이 기본값을 지정하지 않은 경우에 적용되는 상태로 돌아갑니다.

nodefaults

일반 채널 블록과 마찬가지로 빈 행을 사용하여 각 defaults 또는 nodefaults 채널 블록을 다른 채널 블록과 구분해야 합니다. defaults 및 nodefaults 채널 블록은 구성 파일에서 로컬 채널 앞에 표시될 수 있는 유일한 채널 블록입니다. 그러나, 다른 채널 블록과 마찬가지로 이 채널 블록도 마지막 다시 쓰기 규칙 뒤에 표시해야 합니다.

12.2 채널 키워드(알파벳순)

다음 표는 알파벳순으로 나열된 키워드 목록입니다.

12.3 채널 키워드 범주화(기능별)

다음 표는 범주화한 키워드 목록입니다. 표와 범주는 다음과 같습니다.

• 표 12–2 주소 처리 키워드

• 표 12–3 첨부 파일 및 MIME 처리

• 표 12–4 문자 세트 및 8비트 데이터

• 표 12–5 MTA 대기열 영역에서 파일 만들기

• 표 12–6 헤더 키워드

• 표 12–7 받는 채널 일치 및 전환 키워드

• 표 12–8 로깅 및 디버깅 채널 키워드

• 표 12–9 긴 주소 목록 또는 헤더 채널 키워드

• 표 12–10 메일함 필터 채널 키워드

• 표 12–11 NO-SOLICIT SMTP 확장 지원 키워드

• 표 12–12 알림 및 포스트마스터 메시지 키워드

• 표 12–13 제어 및 작업 전송 처리 키워드

• 표 12–14 민감도 제한 키워드

• 표 12–15 메시지, 사용자 할당량, 권한 및 인증 시도의 제한 키워드

• 표 12–16 SMTP 인증, SASL 및 TLS 키워드

• 표 12–17 SMTP 명령 및 프로토콜 키워드

• 표 12–18 TCP/IP 연결 및 DNS 조회 지원 키워드

• 표 12–19 기타 키워드

12.4 SMTP 채널 구성

설치 유형에 따라 Messaging Server는 설치 시 여러 SMTP 채널을 제공합니다(아래 표 참조). 이러한 채널은 SMTP over TCP/IP를 구현합니다. 다중 스레드 TCP SMTP 채널은 디스패처의 제어에 따라 실행되는 다중 스레드 SMTP 서버를 포함합니다. 보내는 SMTP 메일은 tcp_smtp_client 채널 프로그램에서 처리되고 필요한 경우 작업 제어기의 제어에 따라 실행됩니다.

이 절에 설명된 대로 채널 키워드를 추가하거나 제거하여 이러한 채널의 정의를 수정하거나 새 채널을 만들 수 있습니다. 또한, 옵션 파일을 사용하여 TCP/IP 채널의 다양한 특성을 제어할 수 있습니다. 옵션 파일은 MTA 구성 디렉토리(msg-svr-base /config)에 저장하고 x _option으로 이름을 지정해야 합니다. 여기서 x는 채널의 이름입니다. 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference의 Option File을 참조하십시오.

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

• 12.4.1 SMTP 채널 옵션 구성

• 12.4.2 SMTP 명령 및 프로토콜 지원

• 12.4.3 TCP/IP 연결 및 DNS 조회 지원

• 12.4.4 SMTP 인증, SASL 및 TLS

• 12.4.5 헤더의 SMTP AUTH에서 인증된 주소 사용

• 12.4.6 SMTP 청크 지원

• 12.4.7 Microsoft Exchange 게이트웨이 채널 지정

• 12.4.8 전송 계층 보안

12.4.1 SMTP 채널 옵션 구성

TCP/IP 채널 옵션 파일은 TCP/IP 채널의 다양한 특성을 제어합니다. 채널 옵션 파일은 MTA 구성 디렉토리에 저장하고 x_option으로 이름을 지정해야 합니다. 여기서 x는 채널의 이름입니다. 예: /msg-svr-base/config/tcp_local_option

옵션 파일은 하나 이상의 키워드와 관련 값으로 구성됩니다. 예를 들어, 옵션 파일에 DISABLE_EXPAND 키워드를 포함시키고 값을 1로 설정하여 메일링 목록 확장을 비활성화할 수 있습니다.

다른 옵션 파일 키워드를 사용하여 다음을 수행할 수 있습니다.

• 메시지당 허용되는 수신자 수에 대한 제한 설정( ALLOW_RECIPIENTS_PER_TRANSACTION)

• 연결당 허용되는 메시지 수에 대한 제한 설정( ALLOW_TRANSACTIONS_PER_SESSION)

• MTA 로그 파일에 기록되는 정보 유형 세부 조정(LOG_CONNECTION, LOG_TRANPORTINFO)

• 클라이언트 채널 프로그램에 허용되는 최대 동시 아웃바운드 연결 수 지정(MAX_CLIENT_THREADS)

모든 채널 옵션 키워드 및 구문에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

12.4.2 SMTP 명령 및 프로토콜 지원

SMTP 채널이 EHLO, ETRN, EXPN, VRFY 등과 같은 특정 SMTP 명령을 지원하는지 여부를 지정할 수 있습니다. 또한, 채널이 DNS 도메인 확인을 지원하는지 여부, 채널에서 행 종결 기호로 사용되는 문자 등을 지정할 수 있습니다. 이 절은 다음 내용으로 구성되어 있습니다.

• 12.4.2.1 채널 프로토콜 선택 및 행 종결 기호

• 12.4.2.2 EHLO 명령 지원

• 12.4.2.3 ETRN 명령 지원

• 12.4.2.4 VRFY 명령 지원

• 12.4.2.5 EXPN 지원

• 12.4.2.6 DNS 도메인 확인

• 12.4.2.7 문자 세트 레이블링 및 8비트 데이터

• 12.4.2.8 프로토콜 스트리밍

표 12–21은 이 절에서 설명하는 키워드를 요약해서 보여 줍니다.

12.4.2.1 채널 프로토콜 선택 및 행 종결 기호

키워드: smtp, nosmtp, smtp_crlf , smtp_cr, smtp_crorlf, smtp_lf

smtp 및 nosmtp 키워드는 채널이 SMTP 프로토콜을 지원하는지 여부를 지정합니다. smtp 키워드 또는 이 키워드의 변형 중 하나가 모든 SMTP 채널에 필수입니다.

smtp_crlf, smtp_cr, smtp_crorlf 및 smtp_lf 키워드는 SMTP에서 MTA가 행 종결 기호로 사용하는 문자 시퀀스를 지정하는 데 사용될 수 있습니다. smtp_crlf 키워드는 행을 캐리지 리턴(CR) 줄 바꿈(LF) 시퀀스로 종료해야 함을 의미합니다. smtp_lf 또는 smtp 키워드는 선행 CR 없이 LF를 사용할 수 있음을 의미합니다. 마지막으로 smtp_cr은 후행 LF 없이 CR을 사용할 수 있음을 의미합니다. 이러한 옵션은 받는 메일의 처리에만 영향을 미칩니다.

SMTP 표준은 행 종결 기호로 CRLF를 필요로 하기 때문에 MTA는 항상 표준 CRLF 시퀀스를 생성합니다. 여러 가지 smtp 키워드는 MTA에서 추가 비표준 행 종결 기호를 수락할지 여부만 제어합니다. 예를 들어, MTA가 적법한 SMTP 메시지만 수락하고 비표준행 종결 기호가 있는 메시지를 거부하게 하려면 smtp_crlf를 지정할 수 있습니다.

12.4.2.2 EHLO 명령 지원

키워드: ehlo, noehlo, checkehlo

추가 명령 협상을 허용하도록 SMTP 프로토콜이 확장되었습니다(RFC 1869). 이를 위해 RFC 821의 HELO 명령을 대체하는 새 EHLO 명령이 사용됩니다. 확장 SMTP 서버는 지원하는 확장 목록을 제공하여 EHLO에 응답합니다. 확장되지 않은 서버가 알 수 없는 명령 오류를 반환하면 클라이언트는 이전의 HELO 명령을 대신 보냅니다.

이 폴백 전략은 일반적으로 확장된 서버와 확장되지 않은 서버 모두에 잘 적용됩니다. 그러나 RFC 821에 따라 SMTP를 구현하지 않은 서버에서는 문제가 발생할 수 있습니다. 특히, 일부 비호환 서버에서는 알 수 없는 명령을 수신할 경우 연결을 끊는 것으로 알려져 있습니다.

SMTP 클라이언트는 서버에서 HELO를 수신할 때 연결을 끊는 경우 다시 연결한 다음 EHLO를 사용하는 전략을 구현합니다. 원격 서버에서 EHLO를 수신할 때 연결을 끊고 문제 상태로 전환하는 경우에는 이 전략을 적용할 수 없습니다.

이러한 상황에 대처하기 위해 ehlo, noehlo 및 checkehlo 채널 키워드가 제공됩니다. ehlo 키워드는 모든 초기 연결 시도에서 EHLO 명령을 사용하도록 MTA에 지시합니다. noehlo 키워드는 모든 EHLO 명령 사용을 비활성화합니다. checkehlo 키워드는 문자열 “ESMTP”에 대해 원격 SMTP 서버가 반환하는 응답 배너를 테스트합니다. 이 문자열이 있는 경우 EHLO가 사용되고, 없는 경우 HELO가 사용됩니다. 기본 동작은 모든 초기 연결 시도에서 EHLO를 사용하는 것입니다. 배너 행에 문자열 “fire away”가 없는 경우에는 HELO가 사용됩니다. ehlo 및 checkehlo 키워드로부터 발생되는 동작 사이에 위치하는 이 기본 동작에 해당하는 키워드가 없습니다.

12.4.2.3 ETRN 명령 지원

키워드: allowetrn , blocketrn , disableetrn , domainetrn , silentetrn , sendetrn, nosendetrn, novrfy

RFC 1985에 정의되어 있는 ETRN 명령은 SMTP 클라이언트와 서버가 상호 작용하여 서버에서 지정된 호스트로 보낼 메시지 대기열 처리를 시작할 수 있도록 SMTP 서비스를 확장합니다.

SMTP 클라이언트는 ETRN을 사용하여 원격 SMTP 서버에서 SMTP 클라이언트에 보낼 메시지 대기열의 처리를 시작하도록 요청할 수 있습니다. 즉, ETRN을 사용하면 원격 SMTP 시스템에서 수신하는 메시지에 대해 원격 SMTP 시스템 “폴링”을 구현할 수 있습니다. 이 방법은 서로 일시적으로만 연결하는 시스템에 유용할 수 있습니다. 예를 들어, 전화 접속을 통해서만 인터넷에 연결하는 다른 사이트에 대해 보조 MX(Mail eXchange) 호스트로 설정되는 사이트가 있습니다. 이 명령을 사용하여 원격 전화 접속 서버의 메일 전달 요청을 허용합니다.

SMTP 클라이언트는 SMTP ETRN 명령줄에서 메시지를 보낼 시스템의 이름(일반적으로 SMTP 클라이언트 시스템 자체 이름)을 지정합니다. 원격 SMTP 서버가 ETRN 명령을 지원하는 경우 해당 서버는 개별 프로세스를 트리거하여 명명된 시스템에 다시 연결하고 해당 명명된 시스템에 대해 전달 대기 중인 메시지를 보냅니다.

ETRN 명령에 대한 응답

allowetrn, blocketrn, domainetrn 및 silentetrn 키워드는 보내는 SMTP 클라이언트가 MTA에 MTA 대기열의 메시지를 전달하도록 요청하는 ETRN 명령을 실행할 때 MTA 응답을 제어합니다.

기본적으로 MTA는 모든 ETRN 명령을 수락하려고 시도합니다. 즉, allowetrn 키워드가 사용됩니다. 채널 정의에 blocketrn 키워드를 포함하여 MTA에서 ETRN 명령을 수락하지 않도록 지정할 수 있습니다.

silentetrn 키워드를 포함하여 도메인과 일치하고 MTA에서 실행할 채널의 이름을 반향하지 않고 모든 ETRN 명령을 수락하도록 지정할 수 있습니다. domainetrn 키워드는 MTA가 도메인을 지정하는 ETRN 명령만 사용하도록 지정합니다. 또한, 도메인과 일치하고 MTA에서 실행할 채널의 이름을 에코하지 않도록 지정합니다.

disableetrn은 ETRN 명령을 전혀 지원하지 않습니다. ETRN은 SMTP 서버에서 지원되는 명령으로 광고되지 않습니다.

ETRN 명령 보내기

sendetrn 및 nosendetrn 채널 키워드는 MTA가 SMTP 연결을 시작할 때 ETRN 명령을 보내는지 여부를 제어합니다. 기본값은 nosendetrn이며 MTA가 ETRN 명령을 보내지 않음을 의미합니다. sendetrn 키워드는 원격 SMTP 서버가 ETRN을 지원할 경우 ETRN 명령을 보내도록 MTA에 지시합니다. sendetrn 키워드는 메시지가 전달 시도를 받도록 요청하는 시스템 이름 앞에 입력해야 합니다.

12.4.2.4 VRFY 명령 지원

키워드: domainvrfy, localvrfy, vrfyallow, vrfydefault, vrfyhide

VRFY 명령을 사용하면 SMTP 클라이언트가 SMTP 서버에 특정 아이디에 대한 메일이 있는지 확인하라는 요청을 서버에 보낼 수 있습니다. VRFY 명령은 RFC 821에 정의되어 있습니다.

서버는 사용자가 로컬 사용자인지 여부, 메일 전달 여부 등을 나타내는 응답을 보냅니다. 250 응답은 아이디가 로컬임을 나타내고, 251 응답은 아이디가 로컬이 아니지만 서버가 메시지를 전달할 수 있음을 나타냅니다. 서버 응답에는 메일함 이름이 포함되어 있습니다.

VRFY 명령 보내기

정상적인 환경에서는 VRFY 명령을 SMTP 대화 상자의 일부로 실행할 이유가 없습니다. SMTP RCPT TO 명령은 VRFY 명령과 동일한 기능을 수행하고 해당 오류를 반환해야 합니다. RCPT TO에 주소를 받아들인 다음 나중에 바운스할 수 있는 서버가 존재하지만, 이러한 서버는 VRFY 명령의 일부로 보다 집중적인 검사를 수행합니다.

기본적으로 MTA는 VRFY 명령을 보내지 않습니다(novrfy 키워드 사용).

필요한 경우 채널 정의에 domainvrfy 또는 localvrfy 키워드를 포함하여 SMTP VRFY 명령을 실행하도록 MTA를 구성할 수 있습니다. domainvrfy 키워드는 전체 주소(user@host)를 인수로 갖는 VRFY 명령이 실행되게 합니다. localvrfy 키워드는 MTA에서 주소의 로컬 부분(user)만 사용하여 VRFY 명령이 실행되게 합니다.

VRFY 명령에 대한 응답

vrfyallow, vrfydefault 및 vrfyhide 키워드는 보내는 SMTP 클라이언트가 SMTP VRFY 명령을 실행할 때 SMTP 서버의 응답을 제어합니다.

vrfyallow 키워드는 자세한 정보 응답을 실행하도록 MTA에 지시합니다. vrfydefault는 HIDE_VERIFY=1 채널 옵션이 지정되어 있지 않은 경우 자세한 정보 응답을 제공하도록 MTA에 지시합니다. vrfyhide 키워드는 모호한 응답만 생성하도록 MTA에 지시합니다. 이러한 키워드는 동일한 SMTP 서버를 통해 처리되는 모든 받는 TCP/IP 채널에 일반적으로 적용되는 HIDE_VERIFY 옵션과 달리 VRFY 응답을 채널 단위로 제어할 수 있습니다.

12.4.2.5 EXPN 지원

키워드: expnallow , expndisable , expndefault

expnallow는 DISABLE_EXPAND SMTP 채널 옵션을 사용하여 SMTP 서버 수준에서 사용 불가능으로 설정했더라도 EXPN을 허용합니다. expndisable은 EXPN을 무조건적으로 사용 불가능하게 합니다. expndefault는 SMTP 서버에 사용하도록 설정된 경우 EXPN을 허용합니다(기본값). 확장은 목록 단위로 비활성화할 수 있지만 서버 수준에서 비활성화하면 목록별 설정이 부적절하게 됩니다.

12.4.2.6 DNS 도메인 확인

키워드: mailfromdnsverify, nomailfromdnsverify

받는 TCP/IP 채널에서 mailfromdnsverify를 설정하면 MTA는 DNS의 항목이 SMTP MAIL FROM 명령에 사용된 도메인에 있는지 확인하여 해당 항목이 없는 경우 메시지를 거부합니다. 기본값인 nomailfromdnsverify는 확인이 수행되지 않음을 의미합니다. 반송 주소 도메인에 대해 DNS 확인을 수행하면 일부 유효한 메시지가 거부될 수 있습니다. 예를 들어, 도메인 이름을 아직 등록하지 않은 합법적인 사이트에서 또는 DNS에 잘못된 정보가 있는 경우 거부됩니다. 이는 RFC 1123, Requirements for Internet Hosts에 명시되어 있는 전자 메일 수락 및 전달에 있어 관대함을 요구하는 조항에 위반됩니다. 그러나 몇몇 사이트에서는 존재하지 않는 도메인으로부터 위조된 전자 메일 주소로 UBE(Unsolicited Bulk Email)를 받는 경우 그러한 검사를 수행할 수 있습니다.

COM 및 ORG 최상위 도메인에서 DNS 와일드카드 항목이 소개되어 mailfromdnsverify가 별로 유용하지 않게 되었기 때문에 mailfromdnsverify 코드가 수정되었습니다. DNS가 하나 이상의 A 레코드를 반환하면 이러한 값은 새 MTA 옵션 BLOCKED_MAIL_FROM_IPS에 지정된 도메인 리터럴과 비교됩니다. 일치하는 값이 발견되면 도메인은 유효하지 않은 것으로 간주됩니다. 올바른 동작을 복원하기 위한 현재의 올바른 설정은 다음과 같습니다.

BLOCKED_MAIL_FROM_IPS=[64.94.110.11]

이 옵션의 기본값은 빈 문자열입니다.

12.4.2.7 문자 세트 레이블링 및 8비트 데이터

키워드: charset7, charset8, charsetesc, sevenbit, eightbit, eightnegotiate, eightstrict

문자 세트 레이블링

MIME 사양은 일반 텍스트 메시지에 사용되는 문자 세트를 레이블링하는 기법을 제공합니다. 특히 charset= 매개 변수를 Content-type:의 헤더 행으로 지정할 수 있습니다. US-ASCII(기본값), ISO-8859-1, ISO-8859-2 등을 포함하여 다양한 문자 세트 이름이 MIME에 정의되어 있습니다.

일부 기존 시스템과 사용자 에이전트는 이러한 문자 세트 레이블 생성을 위한 기법을 제공하지 않기 때문에 일반 텍스트 메시지가 제대로 레이블링되지 않을 수 있습니다. charset7, charset8 및 charsetesc 채널 키워드는 문자 세트 레이블링이 부족한 메시지 헤더에 삽입할 문자 세트 이름을 지정할 수 있도록 채널 단위 기법을 제공합니다. 각 키워드에는 문자 세트 이름을 지정하는 단일 인수가 필요합니다. 이름의 유효성은 검사하지 않습니다. MTA 테이블 디렉토리에 있는 charsets.txt 문자 세트 정의 파일에 지정된 문자 세트에 대해서만 문자 세트 변환을 수행할 수 있습니다. 가능하면 이 파일에 정의된 이름을 사용해야 합니다.

charset7 문자 세트 이름은 메시지에 7비트 문자만 포함되어 있는 경우에 사용되며, charset8 문자 세트 이름은 메시지에 8비트 데이터가 있는 경우에 사용되고, charsetesc는 7비트 데이터만 포함하는 메시지에 이스케이프 문자도 포함하게 되는 경우에 사용됩니다. 해당 키워드를 지정하지 않으면 Content-type: 헤더 행으로 어떤 문자 세트도 지정되지 않습니다.

또한, charset8 키워드는 8비트 문자는 무조건적으로 부적합한 메시지 헤더에서 8비트 문자의 MIME 인코딩을 제어합니다. MTA는 일반적으로 charset8 값이 지정되어 있지 않은 경우 메시지 헤더에 있는 (잘못된) 8비트 데이터를 UNKNOWN charset으로 레이블링하여 MIME 인코딩합니다.

이러한 문자 세트 사양은 기존 레이블을 대체하지 않습니다. 즉, 메시지에 문자 세트 레이블이 이미 있거나 메시지 유형이 텍스트가 아닌 경우에는 적용되지 않습니다. 이 문자 세트 사양은 MTA 로컬 채널을 다음과 같이 레이블링하는 데 적합합니다.

l ... charset7 US-ASCII charset8 ISO-8859-1 ...
hostname

메시지에 Content-type 헤더가 없는 경우에 추가됩니다. 또한, 이 키워드는 MIME-version: 헤더 행을 추가합니다(없는 경우).

charsetesc 키워드는 이스케이프 문자를 포함하는 일본어 또는 한국어 문자 세트를 사용하는 레이블링되지 않은 메시지를 받는 채널에서 특히 유용합니다.

8비트 데이터

일부 전송에서는 127(십진수)보다 더 큰 서수 값을 갖는 문자의 사용을 제한합니다. 일부 SMTP 서버는 높은 비트를 제거하기 때문에 이 8비트 범위에 속하는 문자를 사용하는 메시지를 제대로 해석하지 못합니다.

Messaging Server는 문제가 있는 8비트 문자가 메시지에 직접 표시되지 않도록 해당 메시지를 자동으로 인코딩하는 기능을 제공합니다. 이 인코딩은 sevenbit 키워드를 지정하여 지정된 채널의 대기열에 포함된 모든 메시지에 적용할 수 있습니다. 이러한 제한이 없는 경우 채널에 eightbit 표시를 해야 합니다.

“원격 SMTP 서버가 8비트를 허용하는 SMTP 확장을 지원한다고 명시하지 않은 경우” SMTP 프로토콜에서 8비트를 사용할 수 없습니다.확장 SMTP와 같은 일부 전송에서는 8비트 문자를 전송할 수 있는지 확인할 수 있도록 협상을 지원하는 경우도 있습니다. 따라서 협상에 실패할 경우 eightnegotiate 키워드를 사용하여 메시지를 인코딩하도록 채널에 지시하는 것이 좋습니다. 이 키워드는 모든 채널의 기본값입니다. 이 경우 협상을 지원하지 않는 채널에서는 8비트 데이터를 전송할 수 없는 것으로 간주합니다.

eightstrict 키워드는 협상되지 않은 8비트 데이터가 포함된 받는 메시지를 거부하도록 Messaging Server에 지시합니다.

12.4.2.8 프로토콜 스트리밍

키워드: streaming

일부 메일 프로토콜에서는 스트리밍 작업을 지원합니다. 이것은 MTA가 한 번에 여러 작업에 대한 명령을 실행하고 각 작업에 대한 응답이 일괄적으로 도착할 때까지 기다릴 수 있음을 의미합니다. streaming 키워드는 채널과 연결된 프로토콜에서 사용되는 프로토콜 스트리밍의 범위를 제어합니다. 이 키워드에는 정수 매개 변수가 필요합니다. 매개 변수를 해석하는 방법은 사용 중인 프로토콜에 따라 다릅니다.

정상적인 환경에서는 SMTP 파이프라인 확장을 사용하여 사용 가능한 스트리밍 범위를 협상합니다. 따라서, 정상적인 환경에서는 이 키워드를 절대 사용하지 마십시오.

사용 가능한 스트리밍 값의 범위는 0부터 3까지입니다. 값 0은 스트리밍을 지정하지 않고, 값 1은 RCPT TO 명령 그룹을 스트리밍하고, 값 2는 MAIL FROM/RCPT TO를 스트리밍하고, 값 3은 HELO/MAIL FROM/RCPT TO 또는 RSET/MAIL FROM/RCPT TO 스트리밍을 사용합니다. 기본값은 0입니다.

12.4.3 TCP/IP 연결 및 DNS 조회 지원

서버에서 TCP/IP 연결 및 주소 조회를 처리하는 방법에 대한 정보를 지정할 수 있습니다. 이 절은 다음 내용으로 구성되어 있습니다.

• 12.4.3.1 TCP/IP 포트 번호 및 인터페이스 주소

• 12.4.3.2 채널 연결 정보 캐싱

• 12.4.3.3 역방향 DNS 조회

• 12.4.3.4 IDENT 조회

• 12.4.3.5 TCP/IP MX 레코드 지원

• 12.4.3.6 이름 서버 조회

• 12.4.3.7 마지막 Resort 호스트

• 12.4.3.8 받는 메일을 위한 대체 채널(전환 채널)

• 12.4.3.9 사용자 또는 도메인 설정을 기준으로 소스 채널 전환

• 12.4.3.10 대상 호스트 선택

표 12–22는 이 절에서 설명하는 TCP/IP 연결 및 DNS 조회 키워드를 보여줍니다.

12.4.3.1 TCP/IP 포트 번호 및 인터페이스 주소

키워드: port, interfaceaddress

SMTP over TCP/IP 채널은 메시지를 보낼 때 일반적으로 포트 25에 연결합니다. port 키워드를 사용하여 비표준 포트에 연결하도록 SMTP over TCP/IP 채널에 지시할 수 있습니다. 이 키워드는 SMTP 연결을 위해 MTA가 수신하는 포트를 제어하는 PORT 디스패처 옵션을 보완합니다.

interfaceaddress 키워드는 TCP/IP 채널이 아웃바운드 연결에 대한 소스 주소로 바인딩하는 주소를 제어합니다. 즉, 여러 인터페이스 주소를 갖는 시스템에서 이 키워드는 MTA가 SMTP 메시지를 보낼 때 소스 IP 주소로 사용하는 주소를 제어합니다. 이 키워드는 받는 연결 및 메시지를 받기 위해 TCP/IP 채널이 수신하는 인터페이스 주소를 제어하는 INTERFACE_ADDRESS 디스패처 옵션을 보완합니다.

12.4.3.2 채널 연결 정보 캐싱

키워드: cacheeverything, nocache, cachefailures, cachesuccesses

SMTP 프로토콜을 사용하는 채널은 이전 연결 시도 내역이 들어 있는 캐시를 유지 관리합니다. 이 캐시를 사용하면 액세스할 수 없는 호스트에 여러 번 다시 연결할 필요가 없으므로 시간이 낭비되거나 다른 메시지가 지연되지 않습니다. 캐시는 프로세스 단위 캐시이며 아웃바운드 SMTP 전달 채널을 한 번 실행하는 동안에만 지속됩니다.

캐시는 일반적으로 연결 성공과 연결 실패를 모두 기록합니다. 성공한 연결 시도는 후속 실패를 오프셋하기 위해 기록됩니다. 그러나, 이전에는 성공했으나 지금은 실패한 호스트에서는 연결을 시도한 적이 없거나 이전에 실패했던 호스트에서처럼 다른 연결을 시도하기 이전에 지연 기간이 보장되지 않습니다.

MTA에 사용되는 캐싱 전략이 모든 상황에 적합한 것은 아닙니다. 따라서 MTA 캐시 조정을 위해 채널 키워드가 제공됩니다.

cacheeverything 키워드는 모든 형식의 캐싱을 사용하며 기본값입니다. nocache 키워드는 모든 캐싱을 사용하지 않습니다.

cachefailures 키워드는 연결 실패 캐싱만 사용하며 cacheeverything 키워드의 경우보다 재시도가 제한됩니다. 마지막으로 cachesuccesses는 연결 성공만 캐시합니다. 이 마지막 키워드는 SMTP 채널의 nocache 키워드와 효과가 동일합니다.

12.4.3.3 역방향 DNS 조회

키워드: forwardchecknone, forwardchecktag, forwardcheckdelete

forwardchecknone, forwardchecktag 및 forwardcheckdelete 채널 키워드는 역방향 DNS 조회 수행 효과를 수정할 수 있습니다. 이러한 키워드는 MTA가 DNS 역방향 조회를 사용하여 찾은 IP 이름에 대해 정방향 조회를 수행하는지 여부를 제어할 수 있으며, 그러한 정방향 조회를 요청받을 경우 IP 이름 정방향 조회가 연결의 원본 IP 번호와 일치하지 않을 때 MTA에서 수행할 작업을 지정합니다.

forwardchecknone 키워드는 기본값이며 정방향 조회가 수행되지 않음을 의미합니다. forwardchecktag 키워드는 각 역방향 조회 이후에 정방향 조회를 수행하고, 정방향 조회를 사용하여 찾은 IP 번호가 원본 연결의 IP 번호와 일치하지 않을 경우 해당 IP 이름에 별표(*) 태그를 붙이도록 MTA에 지시합니다. forwardcheckdelete 키워드는 각 역방향 조회 이후에 정방향 조회를 수행하고 해당 이름에 대한 정방향 조회가 원본 연결 IP 주소와 일치하지 않는 경우 역방향 조회에서 반환된 이름을 무시(삭제)하도록 MTA에 지시합니다. 이 경우 MTA는 원본 IP 주소를 대신 사용합니다.

순방향 조회가 원본 IP 주소와 일치하지 않는 것이 정상인 사이트가 있습니다. 이러한 사이트에서는 여러 IP 주소에 보다 “일반적인” IP 이름을 사용합니다.

12.4.3.4 IDENT 조회

키워드: identnone, identnonelimited, identtnonnumeric, identnonesymbolic, identtcp , identtcpnumeric, identtcpsymbolic, identtcplimited

IDENT 키워드는 MTA에서 IDENT 프로토콜을 사용하여 연결 및 조회를 처리하는 방법을 제어합니다. IDENT 프로토콜은 RFC 1413에 설명되어 있습니다.

identtcp, identtcpsymbolic 및 identtcpnumeric 키워드는 IDENT 프로토콜을 사용하여 연결 및 조회를 수행하도록 MTA에 지시합니다. IDENT 프로토콜에서 가져온 정보(일반적으로 SMTP에 연결한 아이디)는 메시지의 Received: 헤더에 다음과 같이 삽입됩니다.

• identtcp는 받는 IP 번호에 해당하는 호스트 이름(DNS 역방향 조회에서 보고됨)과 IP 번호 자체를 삽입합니다.

• identtcpsymbolic은 받는 IP 번호에 해당하는 호스트 이름(DNS 역방향 조회에서 보고됨)을 삽입합니다. IP 번호 자체는 Received:header.

• identtcpnumeric은 실제 받는 IP 번호를 삽입합니다. IP 번호에 대한 DNS 역방향 조회는 수행되지 않습니다.

identtcp, identtcpsymbolic 또는 identtcpnumeric에 의한 IDENT 조회가 유효하려면 원격 시스템에서 IDENT 서버를 실행해야 합니다.

IDENT 쿼리를 시도하면 성능이 감소될 수 있음에 유의하십시오. 점차적으로 라우터는 자신이 구성하지 않은 포트에 대해 시도된 연결에 “블랙홀”을 생성합니다. IDENT 쿼리에서 이러한 현상이 발생할 경우 MTA는 연결 시간 초과(TCP/IP 스택 제어 시간 초과, 일반적으로 1분 또는 2분)가 발생할 때까지는 다시 수신하지 않습니다.

identtcp, indenttcplimited 또는 identtcpsymbolic을 identtcpnumeric과 비교하는 경우 또 다른 성능 요소가 있습니다. identtcp, identtcplimited 또는 identtcpsymbolic으로 호출되는 DNS 역방향 조회는 사용자에게 보다 친숙한 호스트 이름을 가져오기 위해 추가 오버헤드를 발생시킵니다.

identnone 키워드는 IDENT 조회를 사용하지 않지만 IP를 호스트 이름으로 변환하도록 지정하고 IP 번호와 호스트 이름 모두 메시지의 Received: 헤더에 포함합니다.

identnonesymbolic 키워드는 IDENT 조회를 사용하지 않지만 IP를 호스트 이름으로 변환하며 호스트 이름만 메시지의 Received: 헤더에 포함합니다.

identnonenumeric 키워드는 이 IDENT 조회를 사용하지 않고 일반 DNS 역방향 조회에서 IP 번호를 호스트 이름으로 변환하지 못하게 하며, Received: 헤더에서 사용자가 쉽게 접근하기 어려운 정보를 삭제하여 성능을 향상시킵니다. 기본값입니다.

identtcplimited 및 identnonelimited 키워드는 IDENT 조회, 역방향 DNS 조회 및 Received: 헤더에 표시되는 정보에 있어서 각각 identtcp 및 identnone과 동일한 효과를 가집니다. identtcplimited 또는 identnonelimited에서는 DNS 역방향 조회의 호스트 이름 확인 성공 여부에 관계 없이 switchchannel 키워드의 사용에 따른 채널 전환의 기초로 항상 IP 문자 주소를 사용한다는 점만 다릅니다.

12.4.3.5 TCP/IP MX 레코드 지원

키워드: mx, nomx, defaultmx , randommx, nonrandommx

TCP/IP 네트워크에서 MX(메일 전달) 레코드 사용을 지원하는 경우도 있고 지원하지 않는 경우도 있습니다. 일부 TCP/IP 채널 프로그램에서는 MTA 시스템이 연결된 네트워크에서 MX 레코드를 제공하지 않는 경우 MX 레코드를 사용하지 않도록 구성할 수 있습니다. mx, nomx, defaultmx, randommx, nonrandommx 키워드는 MX 레코드 지원을 제어합니다.

randommx 키워드는 MX 조회를 수행하고 우선 순위가 동일한 MX 레코드 값을 임의의 순서로 처리하도록 지정합니다. nonrandommx 키워드는 MX 조회를 수행하고 우선 순위가 동일한 MX 레코드 값을 받은 순서대로 처리하도록 지정합니다.

mx 키워드는 nonrandommx 키워드에 해당하며 이후의 릴리스에서는 randommx에 해당하는 키워드로 변경될 수 있습니다. nomx 키워드는 MX 조회를 사용하지 않습니다. defaultmx 키워드는 네트워크에서 MX 레코드를 지원할 경우 mx를 사용하도록 지정합니다. defaultmx 키워드는 MX 조회를 지원하는 채널의 기본값입니다.

12.4.3.6 이름 서버 조회

키워드: nameservers, defaultnameservers

이름 서버 조회를 수행할 경우 TCP/IP 스택의 자체 이름 서버 선택을 참조하는 대신 nameservers 채널 키워드를 사용하여 이름 서버 목록을 지정할 수 있습니다. nameservers 키워드에는 다음 예에 표시된 것처럼 이름 서버에 대한 공백으로 구분된 IP 주소 목록이 필요합니다.

nameservers 1.2.3.1 1.2.3.2

기본값인 defaultnameservers는 TCP/IP 스택의 자체 이름 서버 선택을 사용함을 의미합니다.

UNIX에서 이름 서버 조회를 수행하지 않게 하려면 nsswitch.conf 파일을 수정하면 됩니다. NT에서는 TCP/IP 구성을 수정하십시오.

12.4.3.7 마지막 Resort 호스트

키워드: lastresort

lastresort 키워드는 다른 모든 연결 시도가 실패할 경우에 연결할 호스트를 지정하는 데 사용됩니다. 실제로 이 키워드는 마지막 Resort MX 레코드 역할을 합니다. 또한 SMTP 채널에서만 유효합니다.

이 키워드에는 “마지막 Resort 시스템”의 이름을 지정하는 단일 매개 변수가 필요합니다.예를 들면 다음과 같습니다.

tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON

12.4.3.8 받는 메일을 위한 대체 채널(전환 채널)

키워드: switchchannel, allowswitchchannel, noswitchchannel. 12.4.4 SMTP 인증, SASL 및 TLS에 있는 saslswitchchannel, 12.4.8 전송 계층 보안에 있는 tlsswitchchannel 및 12.4.3.9 사용자 또는 도메인 설정을 기준으로 소스 채널 전환에 있는 userswitchchannel을 참조하십시오.

switchchannel, allowswitchchannel, noswitchchannel 키워드는 받는 메일을 위한 대체 채널 선택을 제어합니다.

MTA는 원격 시스템으로부터 받는 연결을 수락할 때 연결에 사용할 채널을 선택해야 합니다. 일반적으로 이 결정은 사용된 전송을 기반으로 합니다. 예를 들어, 받는 SMTP over TCP/IP 연결은 tcp_local 채널에 자동으로 연결됩니다.

서로 다른 특성을 갖는 여러 보내는 채널을 사용하여 동일한 전송을 통해 서로 다른 여러 시스템을 처리할 경우에는 이 규칙이 적용되지 않습니다. 이러한 경우 받는 연결은 보내는 연결과 동일한 채널에 연결되지 않기 때문에 해당 채널 특성이 원격 시스템과 연결되지 않습니다.

switchchannel 키워드를 사용하면 이 문제를 해결할 수 있습니다. 서버가 사용하는 초기 채널에서 switchchannel을 지정하면 연결(원본) 호스트의 IP 주소와 채널 테이블을 비교하여 일치하는 경우 원본 채널이 적절하게 변경됩니다. IP 주소가 일치하지 않거나 원래의 기본 받는 채널에 대한 일치가 발견되는 경우 MTA는 DNS 역방향 조회를 통해 찾은 호스트 이름을 사용하여 선택적으로 일치를 시도할 수 있습니다. 소스 채널이 switchchannel 또는 allowswitchchannel(기본값) 표시가 있는 채널로 변경될 수 있습니다. noswitchchannel 키워드는 채널 전환이 수행되지 않음을 지정합니다.

서버가 연결하는 채널이 아닌 다른 채널에 지정한 switchchannel 키워드는 기본적으로 적용되지 않습니다. 현재는 switchchannel 키워드가 SMTP 채널에만 적용되며 switchchannel을 적용할 수 있는 다른 채널이 없습니다.

12.4.3.9 사용자 또는 도메인 설정을 기준으로 소스 채널 전환

키워드: userswitchchannel. 12.4.3.8 받는 메일을 위한 대체 채널(전환 채널)에 있는 switchchannel을 참조하십시오.

이제 사용자 또는 도메인 설정을 기준으로 소스 채널을 전환할 수 있습니다. 여기에는 다음과 같은 세 가지 새로운 설정이 사용됩니다.

1. 새로운 userswitchchannel 채널 키워드. 사용자 채널을 전환하려면 초기 소스 채널에 이 키워드가 있어야 합니다.

2. 새로운 MTA 옵션 LDAP_DOMAIN_ATTR_SOURCE_CHANNEL은 전환할 채널의 이름이 포함된 도메인 수준 속성의 이름을 지정합니다.

3. 새로운 MTA 옵션 LDAP_SOURCE_CHANNEL은 전환할 채널의 이름이 포함된 사용자 수준 속성의 이름을 지정합니다.

또한, 전환되는 채널을 전환이 허용되도록 설정해야 합니다. 즉, 해당 채널을 noswitchchannel 키워드로 표시할 수 없습니다. MAIL FROM 주소를 다시 작성하여 반환된 정보를 기준으로 전환이 적용됩니다. MAIL FROM 주소는 위조하기 쉬우므로 이 기능을 사용할 때에는 특히 주의해서 사용해야 합니다.

12.4.3.10 대상 호스트 선택

키워드: daemon, single, single_sys

daemon 키워드의 해석과 사용은 적용되는 채널의 유형에 따라 다릅니다.

daemon 키워드는 SMTP 채널에서 대상 호스트 선택을 제어하는 데 사용됩니다.

일반적으로 채널은 처리할 메시지의 봉투 주소에 나열되는 모든 호스트에 연결됩니다. daemon 키워드는 봉투 주소에 관계 없이 특정 원격 시스템(일반적으로 방화벽 또는 메일 허브 시스템)에 대신 연결하도록 채널에 지시하는 데 사용됩니다. 실제 원격 시스템 이름은 다음 예에 표시된 것처럼 daemon 키워드 바로 뒤에 표시되어야 합니다.

tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMON

daemon 키워드 뒤의 인수가 정규화된 도메인 이름이 아닌 경우 해당 인수가 무시되고 채널이 해당 채널의 공식 호스트에 연결됩니다. 공식 호스트는 채널과 연관된 정규화된 호스트 이름이며 세 개 행 채널 블록의 두 번째 행에서 지정할 수 있습니다.

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

또한 공식 호스트를 두 개 행 채널 블록에서 TCP-DAEMON 뒤에 지정하여 아웃바운드 연결 자체를 특정 호스트로 식별하게 할 수 있습니다.

tcp_firewall smtp mx daemon router
TCP-DAEMON firewall.acme.com

방화벽 또는 게이트웨이 시스템 이름을 공식 호스트 이름으로 지정할 경우 다음 예에 표시된 것처럼 daemon 키워드에 지정된 인수가 일반적으로 라우터로 지정됩니다.

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

기타 관련 키워드로는 single 및 single_sys가 있습니다. single 키워드는 채널의 각 대상 주소에 대해 별도의 메시지 복사본을 만들도록 지정합니다. single_sys 키워드는 사용된 각 대상 시스템에 대해 단일 메시지 복사본을 만듭니다. 사용된 키워드에 관계 없이 메시지가 대기열에 있는 각 채널에 대해 해당 메시지 복사본을 하나 이상 만듭니다.

12.4.4 SMTP 인증, SASL 및 TLS

키워드: maysaslserver , mustsaslserver , nosasl, nosaslserver, saslswitchchannel, nosaslswitchchannel)

Messaging Server가 SASL(Simple Authentication and Security Layer)을 사용한 SMTP 서버 인증을 지원하는지 여부를 제어할 수 있습니다. SASL은 RFC 2222에 정의되어 있습니다. SASL, SMTP 인증 및 보안에 대한 자세한 내용은 23 장, 보안 및 액세스 제어 구성을 참조하십시오.

maysaslserver, mustsaslserver, nosasl, nosaslserver, switchchannel 및 saslswitchchannel 채널 키워드는 TCP/IP 채널과 같은 SMTP 채널이 SMTP 프로토콜에서 SASL(SMTP AUTH)을 사용하도록 구성하는 데 사용됩니다.

nosasl이 기본값이며 SASL 인증이 허용 또는 시도되지 않음을 의미합니다. 또한, SASL 인증이 허용되지 않음을 의미하는 nosaslserver를 포함합니다. maysaslserver를 지정하면 SMTP 서버에서 클라이언트가 SASL 인증 사용을 시도하도록 허용합니다. mustsaslserver를 지정하면 SMTP 서버에서 클라이언트가 SASL 인증을 사용하려고 시도하지만 SMTP 서버는 원격 클라이언트가 성공적으로 인증되지 않는 경우 메시지를 수락하지 않습니다.

saslswitchchannel을 사용하면 클라이언트가 SASL을 성공적으로 사용할 경우에 받는 연결이 지정한 채널로 전환되게 합니다. 전환할 채널을 지정하는 필수 값을 사용합니다.

12.4.5 헤더의 SMTP AUTH에서 인증된 주소 사용

키워드: authrewrite

authrewrite 채널 키워드 및 관련 AUTH_REWRITE 매핑 테이블을 사용하면 인증 작업에서 얻은 주소 지정 정보를 사용하여 헤더 및 봉투 주소를 수정할 수 있습니다. 특히 인증된 전자 메일 주소를 제공하도록 SASL 인증을 구성할 수 있습니다. 일반적으로 SMTP AUTH 정보가 사용되지만 이 정보는 FROM_ACCESS 매핑을 통해 대체될 수 있습니다. authrewrite 키워드는 표 12–23에 따라 필수 비트 값을 가집니다.

$Z 플래그는 봉투와 헤더 주소를 수정하기 위해 합법적으로 사용하는 경우는 적으므로 높은 수준으로 제한되어야 합니다.

12.4.6 SMTP 청크 지원

키워드: chunkingclient, chunkingserver, nochunkingclient, nochunkingserver

SMTP 청크(RFC 3030)에 대한 지원이 SMTP 클라이언트와 서버 모두에 추가되었습니다. 이 지원은 기본적으로 활성화됩니다. 청크 허용 여부를 제어할 때 4개의 새 채널 키워드를 사용할 수 있습니다. 이러한 키워드는 다음과 같습니다.

• chunkingclient - 클라이언트 청크 지원을 활성화합니다(기본값).

• chunkingserver - 서버 청크 지원을 활성화합니다(기본값).

• nochunkingclient - 클라이언트 청크 지원을 비활성화합니다.

• nochunkingserver - 서버 청크 지원을 비활성화합니다.

지정된 메시지 전송에 청크가 사용되었는지 여부를 나타내도록 로그 파일 작업 필드가 확장되었습니다. 특히 청크가 사용될 경우 C가 추가됩니다. 청크가 작동하려면 ESMTP를 사용해야 하므로 일반적으로 EEC 또는 DEC와 같은 필드 값이 표시됩니다.

12.4.7 Microsoft Exchange 게이트웨이 채널 지정

키워드: msexchange, nomsexchange

TCP/IP 채널에서 msexchange 채널 키워드를 사용하여 이 채널이 Microsoft Exchange 게이트웨이 및 클라이언트와 통신하는 채널임을 MTA에 알려줄 수 있습니다. 이 채널 키워드를 maysaslserver 또는 mustsaslserver 키워드를 통해 SASL을 사용하는 받는 TCP/IP 채널에 넣을 경우 MTA의 SMTP 서버가 “잘못된” 형식(새로 수정된 AUTH 사양 대신 올바른 ESMTP 사용과 호환되지 않는 원본의 ESMTP AUTH 사양을 기반으로 함)을 사용하여 AUTH를 광고하게 합니다. 예를 들어, 일부 Microsoft Exchange 클라이언트는 올바른 AUTH 형식을 인식하지 않고 잘못된 AUTH 형식만 인식합니다.

또한, msexchange 채널 키워드는 끊어진 TLS 명령을 광고 및 인식하게 합니다.

기본값은 nomsexchange입니다.

12.4.8 전송 계층 보안

키워드: maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel

maytls, maytlsclient, maytlsserver, musttls, musttlsclient , musttlsserver, notls, notlsclient, notlsserver 및 tlsswitchchannel 채널 키워드는 TCP/IP 채널과 같은 SMTP 기반 채널에 의한 SMTP 프로토콜에서 TLS 사용을 구성하는 데 사용됩니다.

기본값은 notls이고 TLS가 허용 또는 시도되지 않음을 의미합니다. 보내는 연결에서 MTA SMTP 클라이언트가 TLS 사용을 시도하지 않음(보내는 연결 중에 STARTTLS 명령 실행 안 됨)을 의미하는 notlsclient 키워드와 받는 연결에서 MTA SMTP 서버의 TLS 사용이 허용되지 않음(SMTP 서버에서 STARTTLS 확장을 광고하지 않고 명령 자체도 허용 안 됨)을 의미하는 notlsserver 키워드를 포함합니다.

maytls를 지정하면 MTA가 받는 연결에 TLS를 제공하고 보내는 연결에서 TLS를 시도합니다. TLS를 지원하는 SMTP 서버에 메시지를 보낼 때 MTA SMTP 클라이언트가 TLS 사용을 시도함을 의미하는 maytlsclient 키워드와 MTA SMTP 서버가 STARTTLS 확장 지원을 광고하고 메시지를 받을 때 TLS 사용을 허용함을 의미하는 maytlsserver 키워드를 포함합니다.

TLS로 작업할 경우 다음 조건을 충족시켜야 합니다.

• mailsrv 계정에서 파일에 액세스할 수 있도록 인증서의 보호/소유권을 설정해야 합니다.

• mailsrv 계정에서 인증서가 저장되는 디렉토리 내의 파일에 액세스할 수 있도록 해당 디렉토리에서 보호/소유권을 설정해야 합니다.

musttls를 지정하면 MTA가 보내는 연결과 받는 연결 모두에서 TLS 사용을 주장하게 되므로 TLS 사용 협상에 실패할 경우 원격 시스템과 전자 메일을 교환할 수 없습니다. MTA SMTP 클라이언트가 메시지를 보낼 때 TLS 사용을 주장하고 TLS 사용 협상(MTA가 STARTTLS 명령을 실행하고 해당 명령이 성공해야 함)에 실패한 SMTP 서버에 메시지를 보내지 않음을 의미하는 musttlsclient를 포함합니다. 또한, MTA SMTP 서버가 STARTTLS 확장 지원을 광고하고 메시지를 받을 때 TLS 사용을 강제하고 TLS 사용 협상에 실패한 클라이언트에서 보낸 메시지를 받지 않음을 의미하는 musttlsserver를 포함합니다.

tlsswitchchannel 키워드를 사용하면 클라이언트가 SASL 협상에 성공할 경우 받는 연결이 지정한 채널로 전환됩니다. 전환할 채널을 지정하는 필수 값을 사용합니다.

12.5 메시지 처리 및 전달 구성

서버가 특정 기준에 따라 메시지 전달을 시도하도록 구성할 수 있습니다. 또한, 서비스 작업 처리 제한, 새 SMTP 채널 스레드 생성 시기 등과 같은 작업 처리 매개 변수를 지정할 수 있습니다. 이 절은 다음 내용으로 구성되어 있습니다.

• 12.5.1 채널 방향 설정

• 12.5.2 지연 전달 날짜 구현

• 12.5.3 전달에 실패한 메시지에 대한 재시도 간격 지정

• 12.5.4 채널 실행 작업의 처리 풀

• 12.5.5 서비스 작업 제한

• 12.5.7 크기 기반 메시지 우선 순위

• 12.5.8 SMTP 채널 스레드

• 12.5.9 여러 주소 확장

• 12.5.10 서비스 변환 사용

메시지 처리 및 전달에 대한 개념 정보는 표 12–24를 참조하십시오.

12.5 메시지 처리 및 전달 구성은 이 절에서 설명하는 키워드를 요약해서 보여 줍니다.

12.5.1 채널 방향 설정

키워드: master, slave, bidirectional

세 키워드를 사용하여 채널이 마스터 프로그램(master), 슬레이브 프로그램(slave) 또는 두 프로그램 모두(bidirectional) 중 어느 것에서 사용되는지 지정합니다. 이 키워드를 지정하지 않을 경우 기본값은 bidirectional입니다. 이러한 키워드는 메시지를 채널의 대기열에 넣을 때 MTA가 전달 작업을 시작하는지 여부를 지정합니다.

이러한 키워드의 사용은 해당 채널 프로그램의 기본 특성을 반영합니다. MTA가 지원하는 다양한 채널 설명은 이러한 키워드를 사용해야 하는 시기와 위치를 나타냅니다.

12.5.2 지연 전달 날짜 구현

키워드: deferred, nodeferred, immnonurgent

deferred 채널 키워드는 Deferred-delivery: 헤더 행을 인식하고 준수합니다. deferred 전달 날짜가 미래 날짜인 메시지는 해당 날짜가 만료되어 반환되거나 지연 전달 날짜가 될 때까지 채널 대기열에 보관됩니다. Deferred-delivery: 헤더 행의 형식 및 작업에 대한 자세한 내용은 RFC 1327을 참조하십시오.

기본값은 nodeferred 키워드입니다. 지연 메시지 처리에 대한 지원이 RFC 1327에 규정되어 있지만 지연 메시지 처리를 실제로 구현하면 메일 시스템을 디스크 할당량의 확장으로 효과적으로 사용할 수 있습니다.

키워드 immnonurgent는 높음, 중간 및 낮음 우선 순위 메시지를 제출하면 바로 전달을 시작합니다.

12.5.3 전달에 실패한 메시지에 대한 재시도 간격 지정

키워드: backoff , nonurgentbackoff, normalbackoff, urgentbackoff, notices

기본적으로 전달에 실패한 메시지에 대한 전달 재시도 간격은 메시지의 우선 순위에 따라 다릅니다. 전달 시도 사이의 기본 간격(분)은 아래에 나와 있습니다. 우선 순위 뒤의 첫 번째 숫자는 최초 전달 실패 후 첫 번째 전달 재시도가 시도될 때까지의 시간(분)을 나타냅니다.

urgent: 30, 60, 60, 120, 120, 120, 240
normal: 60, 120, 120, 240, 240, 240, 480
nonurgent: 120, 240, 240, 480, 480, 480, 960

우선 순위가 높은 메시지의 경우 최초 전달 실패 후 30분 뒤, 첫 번째 전달 재시도 후 60분 뒤, 두 번째 재시도 후 60분 뒤, 세 번째 재시도 후 120분 뒤 등의 간격으로 재시도가 시도됩니다. 지정된 마지막 시도 이후의 재시도는 동일한 간격으로 반복됩니다. 따라서, 우선 순위가 높은 메시지는 이러한 전달 재시도가 240분 간격으로 수행됩니다.

전달 시도는 notices, nonurgentnotices, normalnotices 또는 urgentnotices 키워드에 지정된 기간 동안 계속됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메시지는 보낸 사람에게 반환됩니다. notices 키워드에 대한 자세한 내용은 10.10.4.3 알림 메일 전달 간격 설정을 참조하십시오.

backoff 키워드를 사용하면 다양한 우선 순위를 갖는 메시지에 대한 전달 재시도 간격 설정을 사용자 정의할 수 있습니다. nonurgentbackoff는 우선 순위가 낮은 메시지에 대한 간격을 지정하고, normalbackoff는 우선 순위가 보통인 메시지에 대한 간격을 지정하고, urgentbackoff는 우선 순위가 높은 메시지에 대한 간격을 지정합니다. 이러한 키워드를 지정하지 않으면 우선 순위에 관계 없이 backoff에 의해 모든 메시지에 대한 간격이 지정됩니다.

예를 들면 다음과 같습니다.

urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"

여기서 우선 순위가 높은 메시지의 경우 최초 전달 실패 후 30분 뒤, 첫 번째 전달 시도 후 1시간 뒤(최초 실패 후 1시간 30분 뒤), 두 번째 전달 시도 후 2시간 뒤, 세 번째 시도 후 3시간 뒤, 네 번째 시도 후 4시간 뒤, 다섯 번째 시도 후 5시간 뒤, 여섯 번째 시도 후 8시간 뒤, 일곱 번째 전달 시도 후 16시간 뒤에 각각 전달 재시도가 수행됩니다. 후속 시도는 notices 키워드에 지정된 기간까지 16시간마다 수행됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메시지는 보낸 사람에게 반환됩니다. 간격 구문은 ISO 8601P에 나와 있으며 Sun Java System Messaging Server Administration Reference에도 설명되어 있습니다.

다음 예에서,

normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d” "p1w"

우선 순위가 보통인 메시지의 경우 최초 전달 실패 후 30분 뒤, 첫 번째 전달 시도 후 1시간 뒤, 두 번째 시도 후 8시간 뒤, 세 번째 시도 후 1일 뒤, 네 번째 시도 후 2일 뒤, 다섯 번째 시도 후 1주일 뒤에 전달 재시도가 각각 수행되고 이후에는 notices 키워드에 지정된 기간까지 1주일마다 전달 재시도가 반복됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메시지는 보낸 사람에게 반환됩니다.

마지막 예에서,

backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"

모든 실패한 메시지의 경우 nonurgentbackoff, normalbackoff 또는 urgentbackoff 키워드에 의해 대체되지 않는 한, 메시지 우선 순위에 관계 없이 최초 전달 실패 후 30분 뒤, 첫 번째 재시도 후 2시간 뒤, 두 번째 재시도 후 16시간 뒤, 세 번째 재시도 후 36시간 뒤, 네 번째 재시도 후 3일 뒤에 전달 재시도가 각각 수행되고 이후에는 notices 키워드에 지정된 기간까지 3일마다 전달 재시도가 수행됩니다. 전달이 성공적으로 이루어질 수 없으면 전달 실패 알림이 생성되고 메시지는 보낸 사람에게 반환됩니다.

12.5.4 채널 실행 작업의 처리 풀

키워드: pool

채널을 동일한 풀 내에서 실행하여 여러 채널이 자원을 공유하도록 구성할 수 있습니다. 다른 채널을 특정 채널에 전용인 풀에서 실행하도록 구성할 수 있습니다. 각 풀 내에서 메시지는 메시지 우선 순위에 따라 서로 다른 처리 대기열에 자동으로 정렬됩니다. 풀 내에서 우선 순위가 높은 메시지가 우선 순위가 낮은 메시지보다 먼저 처리됩니다. 12.5.7 크기 기반 메시지 우선 순위를 참조하십시오.

pool 키워드를 사용하면 작업이 만들어지는 풀을 채널 단위로 선택할 수 있습니다. pool 키워드는 현재 채널에 대한 전달 작업을 풀링해야 하는 풀 이름 앞에 와야 합니다. 풀 이름은 11자를 초과할 수 없습니다.

작업 제어기 개념 및 구성에 대한 자세한 내용은 10.4.8 작업 제어기 파일, 10.4.8 작업 제어기 파일 및 12.5.5 서비스 작업 제한을 참조하십시오.

12.5.5 서비스 작업 제한

키워드: maxjobs, filesperjob

메시지가 채널의 대기열에 배치될 때마다 작업 제어기는 해당 메시지를 전달하기 위해 실행 중인 작업이 있는지 확인합니다. 여기에는 새 작업 프로세스를 시작하거나, 스레드를 추가하거나, 단순히 작업이 이미 실행 중인지 확인하는 것이 포함됩니다. 단일 서비스 작업으로 모든 메시지 전달을 확인하지 못할 수도 있습니다. 작업 제어기 개념 및 구성에 대한 자세한 내용은 10.4.8 작업 제어기 파일, 12.5.4 채널 실행 작업의 처리 풀 및 8.7 작업 제어기를 참조하십시오.

특정 설치의 경우 메시지 전달을 위해 시작할 프로세스 및 스레드에 대한 합리적인 최대 수가 있습니다. 이 최대 수는 프로세서 수, 디스크 속도, 연결 특징 등의 요인에 따라 다릅니다. MTA 구성에서는 다음을 제어할 수 있습니다.

• 지정된 채널에 대해 실행할 최대 프로세스 수(maxjobs 채널 키워드)

• 채널 집합에 대해 시작할 최대 프로세스 수(작업 제어기 구성 파일의 관련 풀 섹션에 있는 JOB_LIMIT 매개 변수)

• 새 스레드 또는 프로세스를 시작하기 전에 받은 대기열에 포함된 메시지 수(threaddepth 채널 키워드)

• 일부 채널의 경우 지정된 전달 프로그램 내에서 실행되는 최대 스레드 수(채널 옵션 파일에 있는 max_client_threads 매개 변수)

지정된 채널에 대해 실행을 시작하는 최대 프로세스 수는 채널에 설정된 maxjobs의 최대값이며 채널이 실행되는 풀에 대해 설정된 JOB_LIMIT입니다.

메시지를 처리해야 한다고 가정합니다. 일반적으로 작업 제어기는 새 프로세스를 다음과 같이 시작합니다.

• 채널에 대해 실행 중인 프로세스가 없고 풀 작업 제한에 도달하지 않은 경우 작업 제어기는 새 프로세스를 시작합니다.

• 채널 프로그램이 단일 스레드이거나 스레드 제한에 도달하고 백로그가 threaddepth에 지정된 스레드 수의 배 이상으로 증가하고 채널 및 풀 작업 제한에 도달하지 않은 경우 작업 제어기는 새 프로세스를 시작합니다.

• 채널 프로그램이 다중 스레드이고 스레드 제한에 도달하지 않았으며, 메시지 백로그가 threaddepth의 2배 이상으로 증가한 경우 새 스레드가 시작됩니다.

특히, SMTP 채널의 경우 서로 다른 호스트에 대한 대기열에 메시지가 포함될 경우 새 스레드 또는 프로세스가 시작됩니다. 따라서, SMTP 채널의 경우 작업 제어기는 새 프로세스를 다음과 같이 시작합니다. 메시지를 처리해야 한다고 가정합니다.

• SMTP 채널에 대해 실행 중인 프로세스가 없고 풀 제한에 도달하지 않은 경우 작업 제어기는 새 프로세스를 시작합니다.

• 스레드 제한(MAX_CLIENT_THREADS)에 도달하고, 아직 사용되고 있지 않은 호스트의 대기열에 메시지가 포함되고, 채널(maxjobs) 및 풀 작업 제한(JOB_LIMIT)에 도달하지 않은 경우 새 프로세스가 시작됩니다.

• 스레드 제한에 도달하지 않고 아직 사용되고 있지 않은 호스트의 대기열에 메시지가 포함될 경우 새 스레드가 시작됩니다.

• 스레드 제한에 도달하지 않았으며 메시지가 대기열에 포함되어 해당 호스트에 대한 메시지 백로그가 threaddepth의 2배 이상으로 증가할 경우 새 스레드가 시작됩니다.

12.5.8 SMTP 채널 스레드를 참조하십시오.

filesperjob 키워드를 사용하여 MTA에서 추가 서비스 작업을 만들 수 있습니다. 이 키워드는 여러 서비스 작업을 만들어 처리하기 전에 연결된 채널로 보내야 하는 대기열 항목(파일) 수를 지정하는 단일의 양의 정수 매개 변수를 가집니다. 0보다 작거나 같은 값을 지정하면 하나의 서비스 작업만 대기열에 포함하라는 요청으로 해석됩니다. 키워드를 지정하지 않으면 0의 값을 지정한 것과 같습니다. 이 키워드의 효과는 최대화됩니다. 즉, 계산된 높은 숫자가 실제로 만들어지는 서비스 작업 수가 됩니다.

filesperjob 키워드는 실제 대기열 항목 또는 파일 수를 지정된 값으로 나눕니다. 지정된 메시지의 대기열 항목 수는 single 및 single_sys 키워드의 사용, 메일링 목록의 헤더 수정 작업 사양 등 많은 요소에 의해 제어됩니다.

maxjobs 키워드는 동시에 실행될 수 있는 총 서비스 작업 수에 대한 최대값을 지정합니다. 이 키워드는 정수 값이 뒤에 와야 합니다. 계산된 서비스 작업 수가 이 값보다 더 큰 경우 maxjobs 작업만 실제로 만들어집니다. maxjobs를 지정하지 않은 경우 이 값의 기본값은 100입니다. 일반적으로 maxjobs는 채널이 사용되는 서비스 풀에 관계 없이 동시에 실행될 수 있는 총 작업 수보다 작거나 같은 값으로 설정됩니다.

12.5.6 연결 트랜잭션 제한 설정

키워드: transactionlimit

transactionlimit는 연결당 허용되는 메시지 수를 제한합니다. 이 키워드를 사용하여 다음과 같은 방법으로 공격자를 차단할 수 있습니다.

공격자가 SMTP를 통해 연결한 다음 많은 RCPT TO 명령을 보내 합법적인 전자 메일 주소를 추측하려고 시도할 수 있습니다. 트랜잭션에 허용되는 유효하지 않은 RCPT TO 수를 제한하여 그런 공격을 차단할 수 있습니다. 공격자는 SMTP 세션에 허용되는 트랜잭션 수를 제한할 수 있는 transactionlimit가 있는 여러 트랜잭션을 사용하여 응답할 수 있습니다. 공격자가 여러 세션을 사용할 수 있지만 과도한 비용이 듭니다. 연결 억제를 사용하여 대부분의 경우에 실제로 많은 비용이 들게 하는 다양한 방법으로 세션 수를 제한할 수 있습니다.

이 비용은 우리 쪽에 부과되는 비용이지만,일부 SMTP 클라이언트는 수신자 제한, 트랜잭션 제한 또는 두 가지 모두에 잘못된 반응을 나타내는 경우도 있습니다. 이러한 클라이언트에 대한 예외를 만들어야 합니다. 그러나, TCP 채널 옵션은 SMTP 서버에 무조건적으로 적용됩니다. 해결책은 채널 키워드와 switchchannel을 사용하여 문제가 있는 에이전트의 경로를 더 큰 제한이 있는 채널로 지정하는 것입니다.

12.5.7 크기 기반 메시지 우선 순위

키워드: urgentblocklimit, normalblocklimit, nonurgentblocklimit

urgentblocklimit, normalblocklimit 및 nonurgentblocklimit 키워드를 사용하여 MTA에 크기 기반 메시지의 우선 순위를 낮추도록 지시할 수 있습니다. 이러한 키워드는 메시지를 처리할 때 작업 제어기가 적용하는 우선 순위에 영향을 미칩니다.

12.5.8 SMTP 채널 스레드

키워드: threaddepth,

다중 스레드 SMTP 클라이언트는 각 스레드에 대한 대상별로 보내는 메시지를 정렬합니다. threaddepth 키워드를 사용하면 다중 스레드 SMTP 클라이언트에 한 스레드에서 지정된 수의 메시지만 처리하도록 지시하여 대상이 같은 메시지(일반적으로 한 스레드에서 모두 처리됨)일 경우에도 추가 스레드를 사용하게 할 수 있습니다. 이 키워드의 기본값은 10입니다.

채널의 백로그가 threaddepth의 배 이상으로 증가할 때마다 작업 제어기는 해당 채널의 대기열에 포함된 메시지 처리를 전담하는 처리량을 높이려고 시도합니다. 다중 스레드 채널의 경우 작업 제어기는 해당 채널에 대한 메시지를 처리하는 작업에서 새 스레드를 시작하게 합니다. 또는 모든 작업이 해당 채널에 대해 허용된 최대 수의 스레드(tcp_* 채널에 대한 옵션의 MAX_CLIENT_THREADS)를 갖는 경우 새 프로세스를 시작합니다. 단일 스레드 채널의 경우 새 프로세스를 시작합니다. 채널에 대한 작업 제한(maxjobs) 또는 풀에 대한 작업 제한(JOB_LIMIT)에 도달한 경우 작업 제어기는 새 작업을 시작하지 않습니다.

기본적으로 threaddepth는 적극적인 작업을 예약하는 방법을 제어합니다. 다음의 두 가지 다른 상황을 고려해 보겠습니다.

(1) 일반(아웃바운드) SMTP 채널

(2) 스마트 호스트에 전달하는 SMTP 채널

작업 제어기는 특정 채널을 대상으로 하는 메시지를 대상 호스트별로 정렬하고 이러한 대상 호스트의 백로그에 기초하여 메시지를 처리하기 위한 작업을 예약합니다.

첫 번째 경우는 많은 수의 대상 호스트가 있고 대상 호스트의 백로그가 대부분 작습니다. 실행되는 스레드의 수가 많으며 aol, yahoo, hotmail 등과 같이 대량의 트래픽이 있을 수 있는 대상 호스트를 제외하고는 모두 제대로 작동합니다. 스레드 깊이가 128인 경우 백로그가 128에 도달하면 yahoo에 전달되는 두 번째 스레드만 가져오게 됩니다. 이는 바람직하지 않습니다.

두 번째 경우는 대상 호스트가 하나만 존재하며 해당 호스트에 많은 수의 스레드를 전달 하는 것이 바람직합니다. 어느 경우든 기본값 10은 너무 작을 수 있습니다.

threaddepth를 사용하면 채널이 연결하는 SMTP 서버에서 여러 동시 연결을 처리할 수 있을 때 데몬 라우터 TCP/IP 채널(단일의 특정 SMTP에 연결하는 TCP/IP 채널)에서 다중 스레딩을 수행하는 데 특히 유용합니다.

12.5.9 여러 주소 확장

키워드: expandlimit, expandchannel, holdlimit

대부분의 채널은 각 인바운드 메시지 전송에서 여러 수신자 주소 사양을 지원합니다. 단일 메시지에 많은 수신자 주소가 있는 사양에서는 메시지 전송 처리가 지연될 수 있습니다(온라인 지연). 너무 오래 지연될 경우 네트워크 시간 초과가 발생하여 메시지 제출 시도가 반복되거나 기타 문제가 발생할 수 있습니다.

MTA는 단일 메시지에 대해 지정된 수보다 더 많은 주소를 지정할 경우 지연(오프라인) 처리를 강제하는 특수 기능을 제공합니다. 메시지 처리 지연은 온라인 지연을 대폭 줄일 수 있습니다. 그러나 처리 오버헤드가 지연되지만 완전히 제거되지는 않습니다.

예를 들어, 일반 reprocessing 채널과 expandlimit 키워드를 함께 사용하면 이 특수 기능이 활성화됩니다. expandlimit 키워드는 지연 처리 이전에 채널에서 받은 메시지에 허용되는 주소 수를 지정하는 정수 인수를 가집니다. expandlimit 키워드를 지정하지 않은 경우 기본값은 무제한입니다. 값이 0이면 채널에서 수신하는 모든 주소에서 지연 처리를 수행합니다.

로컬 채널 또는 reprocessing 채널 자체에는 expandlimit 키워드를 지정하면 안 됩니다. 이러한 키워드를 지정하면 예상치 못한 결과가 발생할 수 있습니다.

지연 처리를 수행하는 데 실제로 사용되는 채널은 expandchannel 키워드를 사용하여 지정할 수 있습니다. expandchannel을 지정하지 않은 경우 reprocessing 채널이 기본적으로 사용되지만 다른 reprocessing 또는 processing 채널을 사용하는 것이 유용한 경우도 있습니다. expandchannel을 통해 지연 처리를 위한 채널을 지정하는 경우 해당 채널이 reprocessing 또는 processing 채널이어야 합니다. 다른 종류의 채널 사양은 예측할 수 없는 결과를 초래할 수 있습니다.

expandlimit 키워드를 적용하려면 reprocessing 채널이나 지연 처리를 수행하는 데 사용되는 모든 채널을 MTA 구성 파일에 추가해야 합니다. MTA 구성 유틸리티를 사용하여 구성을 작성한 경우 reprocessing 채널이 이미 있어야 합니다.

지나치게 큰 수신자 주소 목록은 UBE(Unsolicited Bulk Email) 특성을 가질 수 있습니다. holdlimit 키워드는 수신자가 지정된 수보다 많은 채널에서 수신하는 메시지에 .HELD 메시지 표시를 하고 reprocess 채널 또는 expandchannel 키워드를 통해 지정한 모든 채널의 대기열에 포함하도록 MTA에 지시합니다. 이러한 파일은 MTA 포스트마스터가 수동으로 처리할 때까지 reprocess 대기열에 처리되지 않은 상태로 유지됩니다.

12.5.10 서비스 변환 사용

키워드: service, noservice

service 키워드는 CHARSET-CONVERSION 항목에 관계 없이 서비스 변환을 무조건적으로 사용합니다. noservice 키워드를 설정하면 이 채널에 수신되는 메시지에 대해 CHARSET-CONVERSION을 통해 서비스 변환을 사용해야 합니다.

12.6 주소 처리 구성

이 절에서는 주소 처리를 수행하는 키워드에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

• 12.5.10 서비스 변환 사용

• 12.6.1 주소 유형 및 규칙

• 12.6.2 ! 및 %를 사용하는 주소 해석

• 12.6.3 주소에 라우팅 정보 추가

• 12.6.4 명시적 라우팅 주소의 다시 쓰기 사용 안 함

• 12.6.5 메시지를 대기열에서 제거할 때 주소 다시 쓰기

• 12.6.6 불완전한 주소를 수정할 때 사용할 호스트 이름 지정

• 12.6.7 수신자 헤더 행 없이 메시지 적법화

• 12.6.8 잘못된 빈 수신자 헤더 스트라이핑

• 12.6.9 역방향 데이터베이스의 채널별 사용

• 12.6.10 제한된 메일함 인코딩 사용

• 12.6.11 Return-path: 헤더 행 생성

• 12.6.12 봉투의 To: 및 From: 주소에서 Received: 헤더 행 구성

• 12.6.13 주소 헤더 행의 주석 처리

• 12.6.14 주소 헤더 행에서 개인 이름 처리

• 12.6.15 별칭 파일 및 별칭 데이터베이스 검사 지정

• 12.6.16 하위 주소 처리

• 12.6.17 채널별 다시 쓰기 규칙 검사 사용

• 12.6.18 소스 경로 제거

• 12.6.19 반드시 별칭을 통해 주소 지정

12.6.1 주소 유형 및 규칙

키워드: 822, 733, uucp, header_822, header_733, header_uucp

이 키워드 그룹은 채널에서 지원하는 주소 유형을 제어합니다. 전송 계층(메시지 봉투)에 사용되는 주소와 메시지 헤더에 사용되는 주소를 구분합니다.

12.6.1.1 822(sourceroute)

소스 경로 봉투 주소입니다. 이 채널은 소스 경로를 포함하여 전체 RFC 822 형식의 봉투 주소 지정 규칙을 지원합니다. sourceroute 키워드를 822와 동의어로 사용할 수도 있습니다. 이 키워드는 다른 봉투 주소 유형 키워드를 지정하지 않은 경우의 기본값입니다.

12.6.1.2 733(percents)

백분율(%) 기호 봉투 주소입니다. 이 채널은 소스 경로를 제외한 전체 RFC 822 형식의 봉투 주소 지정을 지원합니다. 소스 경로는 백분율(%) 기호 규칙을 대신 사용하여 다시 작성해야 합니다. percents 키워드는 733의 동의어로 사용할 수 있습니다.

SMTP 채널에서 733 주소 규칙을 사용하면 이러한 규칙이 SMTP 봉투의 전송 계층 주소에 적용됩니다. 그렇게 하면 RFC 821을 위반할 수 있습니다. 733 주소 규칙은 반드시 필요한 경우에만 사용하십시오.

12.6.1.3 uucp(bangstyle)

뱅 스타일 봉투 주소입니다. 이 채널은 RFC 976 뱅 스타일의 주소 규칙을 준수하는 주소를 봉투에 사용합니다. 이 채널의 예로는 UUCP 채널이 있습니다. bangstyle 키워드는 uucp의 동의어로 사용할 수 있습니다.

12.6.1.4 header_822

소스 경로 헤더 주소입니다. 이 채널은 소스 경로를 포함하여 전체 RFC 822 형식의 헤더 주소 지정 규칙을 지원합니다. 다른 헤더 주소 유형 키워드를 지정하지 않을 경우의 기본값입니다.

12.6.1.5 header_733

백분율(%) 기호 헤더 주소입니다. 이 채널은 소스 경로를 제외한 RFC 822 형식의 헤더 주소 지정을 지원합니다. 소스 경로는 백분율(%) 기호 규칙을 대신 사용하여 다시 작성해야 합니다.

메시지 헤더에 733 주소 규칙을 사용하면 RFC 822 및 RFC 976 위반입니다. 채널이 소스 경로 주소를 처리할 수 없는 시스템에 연결된다고 확신하는 경우에만 이 키워드를 사용하십시오.

12.6.1.6 header_uucp

UUCP 또는 뱅 스타일의 헤더 주소입니다. 이 키워드를 사용하면 RFC 976 위반이므로이 키워드는 사용하지 않는 것이 좋습니다.

12.6.2 ! 및 %를 사용하는 주소 해석

키워드: bangoverpercent, nobangoverpercent, percentonly

주소는 항상 RFC 822 및 RFC 976에 따라 해석되지만 이러한 표준에 맞게 주소가 지정되지 않은 복합 주소를 처리할 경우 애매할 수 있습니다. 특히 A!B%C 형식의 주소는 다음과 같이 해석될 수 있습니다.

• A는 라우팅 호스트로 해석되고 C는 최종 대상 호스트로 해석됩니다.

또는

• C는 라우팅 호스트로 해석되고 A는 최종 대상 호스트로 해석됩니다.

RFC 976은 메일 프로그램이 두 번째 규칙을 사용하여 주소를 해석할 수 있음을 의미하지만, 그런 해석이 반드시 필요하다는 의미는 아닙니다. 첫 번째 해석 방법이 더 좋은 경우도 있습니다.

bangoverpercent 키워드는 첫 번째 A!(B%C) 해석을 적용합니다. nobangoverpercent 키워드는 두 번째(A!B)%C 해석을 적용합니다. 기본값은 nobangoverpercent입니다.

이 키워드는 A!B@C 형식의 주소 처리에 영향을 미치지 않습니다. 이러한 주소는 항상 (A!B)@C로 처리됩니다. 이러한 처리는 RFC 822와 RFC 976 모두에서 필수입니다.

percentonly 키워드는 뱅 경로를 무시합니다. 이 키워드를 설정하면 %이 라우팅으로 해석됩니다.

12.6.3 주소에 라우팅 정보 추가

키워드: exproute, noexproute, improute, noimproute

MTA가 처리하는 주소 지정 모델에서는 모든 시스템이 다른 나머지 시스템의 주소와 다른 시스템에 연결하는 방법을 알고 있는 것으로 가정합니다. 불행하게도 이러한 가정이 모든 경우에 적용되는 것은 아닙니다. 채널이 다른 나머지 시스템에서는 알지 못하는 하나 이상의 시스템(예: 개인 TCP/IP 네트워크의 내부 시스템)에 연결하는 경우가 있습니다. 이 채널의 시스템 주소는 사이트 외부의 원격 시스템에는 적합하지 않을 수 있습니다. 그러한 주소에 회신할 수 있으려면 로컬 시스템을 통해 메시지 경로를 지정하도록 원격 시스템에 알려주는 소스 경로가 해당 주소에 포함되어 있어야 합니다. 그러면 로컬 시스템이 메시지의 경로를 이러한 시스템으로 (자동) 지정할 수 있습니다.

exproute 키워드("explicit routing"의 약어)는 주소를 원격 시스템에 전달할 때 연결된 채널에 명시적 라우팅이 필요함을 MTA에 알려 줍니다. 이 키워드를 한 채널에 지정하면 MTA가 해당 채널과 일치하는 모든 헤더 주소와 모든 봉투의 From: 주소에 로컬 시스템의 이름 또는 로컬 시스템의 현재 별칭을 포함하는 라우팅 정보를 추가합니다. 기본값인 noexproute는 라우팅 정보를 추가하지 않도록 지정합니다.

EXPROUTE_FORWARD 옵션을 사용하여 exproute 작업을 역방향 주소로 제한할 수 있습니다. 다른 시나리오는 MTA가 자체적으로 라우팅을 수행할 수 없는 채널을 통해 시스템에 연결하는 경우입니다. 이 경우 부적합한 시스템에 연결되는 채널에 보낸 메일에 해당 주소가 사용되는 시기를 나타내는 라우팅이 다른 채널과 연결된 모든 주소에 있어야 합니다.

암시적 라우팅과 improute 키워드는 이 상황을 처리하는 데 사용됩니다. MTA는 다른 채널과 일치하는 모든 주소가 improute 표시 채널에 보낸 메일에 사용될 경우 라우팅이 필요함을 알고 있습니다. 기본값인 noimproute는 지정된 채널에서 보내는 메시지의 주소에 라우팅 정보를 추가하지 않도록 지정합니다. IMPROUTE_FORWARD 옵션을 사용하여 improute 작업을 역방향 주소로 제한할 수 있습니다.

exproute 및 improute 키워드의 사용을 절제해야 합니다. 이러한 키워드는 길고 복잡한 주소를 만들기 때문에 다른 시스템에 사용되는 지능적인 라우팅 체계를 손상시킬 수 있습니다. 명시적 라우팅과 암시적 라우팅을 지정된 경로와 혼동해서는 안 됩니다. 지정된 경로는 라우팅 정보를 다시 쓰기 규칙에서 주소로 삽입하는 데 사용됩니다. 이 키워드는 특수 A@B@C 다시 쓰기 규칙 템플리트에 의해 활성화됩니다.

지정된 경로를 활성화하면 헤더와 봉투에 있는 모든 주소에 적용됩니다. 지정된 경로는 특정 다시 쓰기 규칙에 의해 활성화되며 일반적으로 현재 사용 중인 채널과는 관련이 없습니다. 다시 말해서, 명시적 라우팅과 암시적 라우팅은 채널 단위로 제어되며 삽입된 경로 주소는 항상 로컬 시스템입니다.

12.6.4 명시적 라우팅 주소의 다시 쓰기 사용 안 함

키워드: routelocal

routelocal 채널 키워드는 채널에 주소를 다시 쓸 때 MTA가 주소에 명시적 라우팅을 “단락”하게 합니다. 명시적 라우팅 주소(!, % 또는 @ 문자 사용)는 단순화됩니다.

내부 TCP/IP 채널과 같은 “내부” 채널에 이 키워드를 사용하면 SMTP 릴레이 차단 구성을 단순화할 수 있습니다.

명시적 % 또는 다른 라우팅이 필요한 채널에서는 이 키워드를 사용하지 마십시오.

12.6.5 메시지를 대기열에서 제거할 때 주소 다시 쓰기

키워드: connectalias, connectcanonical

MTA는 일반적으로 채널 대기열에 메시지를 넣을 때 주소를 다시 씁니다. 메시지를 대기열에서 제거하는 동안에는 추가 다시 쓰기를 수행하지 않습니다. 그렇게 하면 채널 대기열에 이전 이름으로 주소가 지정된 메시지가 있을 경우 호스트 이름을 변경하면 문제가 발생할 수 있습니다.

connectalias 키워드는 수신자 주소에 나열된 모든 호스트에 전달하도록 MTA에 지시하는 기본값입니다. connectcanonical 키워드는 MTA가 연결되는 시스템의 호스트 별칭에 연결하도록 MTA에 지시합니다.

12.6.6 불완전한 주소를 수정할 때 사용할 호스트 이름 지정

키워드: remotehost, noremotehost, defaulthost, nodefaulthost

MTA는 잘못 구성되거나 호환되지 않는 메일 프로그램 및 SMTP 클라이언트로부터 도메인 이름이 포함되지 않은 주소를 받는 경우가 있습니다. 이 경우 MTA는 이러한 주소를 올바른 주소로 만든 후에 전달을 시도합니다. 이를 위해 MTA는 주소에 도메인 이름을 추가(예: @siroe.com을 mrochek에 추가)합니다.

도메인 이름이 없는 봉투의 To: 주소의 경우 MTA는 항상 로컬 호스트 이름을 추가해야 한다고 가정합니다. 그러나 From: 주소와 같은 다른 주소에서는 MTA SMTP 서버의 경우 두 가지 이상의 도메인 이름 선택 항목(로컬 MTA 호스트 이름과 클라이언트 SMTP가 보고한 원격 호스트 이름)이 있습니다. 세 번째 선택 항목(해당 채널에서 추가할 특정 도메인 이름)이 있는 경우도 있습니다. 처음 두 선택 항목이 특정 빈도로 계속해서 발생할 경우 그 중 하나가 올바를 수 있습니다. 잘못 구성된 SMTP 클라이언트를 처리할 경우 원격 호스트 도메인 이름을 사용하는 것이 좋습니다. SMTP가 메시지를 게시하는 데 사용하는 POP 또는 IMAP 클라이언트와 같은 경량 원격 메일 클라이언트를 처리할 경우 로컬 호스트 도메인 이름을 사용하면 안 됩니다. POP 또는 IMAP와 같은 경량 원격 메일 클라이언트의 경우 클라이언트에 로컬 호스트의 도메인 이름이 아닌 해당 클라이언트의 특정 도메인 이름이 있어야 합니다. 그런 다음 다른 특정 도메인 이름을 추가할 수 있습니다. MTA가 채널 단위로 선택하도록 허용하는 것이 가장 좋습니다.

noremotehost 채널 키워드는 로컬 호스트 이름을 사용하도록 지정합니다. 기본값은 noremotehost 키워드입니다.

defaulthost 채널 키워드는 받는 사용자 아이디에 추가할 특정 호스트 이름을 지정하는 데 사용됩니다. 또한, 해당 채널에서 수신하는 주소(봉투의 From: 및 헤더)를 완성하는 데 사용할 도메인 이름이 뒤에 와야 합니다. Submit 채널의 경우 defaulthost 키워드의 첫 번째 인수가 봉투의 To: 주소에도 적용됩니다. 선택적 두 번째 도메인 이름(하나 이상의 점이 있음)을 봉투의 To: 주소를 완성하는 데 사용하도록 지정할 수 있습니다. 기본값은 nodefaulthost입니다.

앞의 12.4.3.8 받는 메일을 위한 대체 채널(전환 채널) 절에서 설명한 것처럼 switchchannel 키워드를 사용하여 받는 SMTP 연결을 특정 채널에 연결할 수 있습니다. 이 기능을 사용하면 원격 메일 클라이언트를 적절하게 처리될 수 있는 특정 채널에서 그룹화할 수 있습니다. 또한, MTA 호스트에서 네트워크 차원 문제를 해결하려고 시도하는 것보다는 비호환 클라이언트를 여러 개 사용 중인 경우에도 표준 호환 원격 메일 클라이언트를 배포하는 것이 더 간단합니다.

12.6.7 수신자 헤더 행 없이 메시지 적법화

키워드: missingrecipientpolicy

RFC 822(인터넷) 메시지에는To:, Cc: 또는 Bcc: 헤더 행과 같은 수신자 헤더 행이 있어야 합니다. 이러한 헤더 행이 없는 메시지는 잘못된 것입니다. 그럼에도 불구하고 sendmail의 많은 이전 버전과 같은 일부 손상된 사용자 에이전트 및 메일 프로그램에서는 잘못된 메시지를 생성합니다.

missingrecipientpolicy 키워드는 그러한 메시지를 사용하는 방법을 지정하는 정수 값을 취합니다. 기본값은 이 키워드가 명백히 표시되지 않은 경우 1(잘못된 메시지를 변경하지 않고 전달)이 됩니다.

MISSING_RECIPIENT_POLICY 옵션을 사용하여 이 동작에 대한 MTA 시스템 기본값을 설정할 수 있습니다. 초기 Messaging Server 구성에서는 MISSING_RECIPIENT_POLICY가 1로 설정됩니다.

12.6.8 잘못된 빈 수신자 헤더 스트라이핑

키워드: dropblank, nodropblank

RFC 822(인터넷) 메시지에서 To:, Resent-To:, Cc: 또는 Resent-Cc: 헤더에는 하나 이상의 주소가 포함되어 있어야 합니다. 이러한 헤더는 빈 값을 가질 수 없습니다. 그럼에도 불구하고 일부 메일 프로그램은 잘못된 헤더를 생성할 수 있습니다. dropblank 채널 키워드를 소스 채널에 지정한 경우 MTA는 받는 메시지에서 잘못된 빈 헤더를 제거합니다.

12.6.9 역방향 데이터베이스의 채널별 사용

키워드: reverse, noreverse

reverse 키워드는 채널 대기열에 포함된 메시지의 주소를 주소 역방향 데이터베이스 또는 REVERSE 매핑을 통해 검색하여 수정(있는 경우)하도록 지시합니다. noreverse는 채널 대기열에 포함된 메시지의 주소를 주소 역방향 처리에서 제외합니다. 기본값은 reverse 키워드입니다. 10.9 주소를 내부 형식에서 공개 형식으로 변환을 참조하십시오.

12.6.10 제한된 메일함 인코딩 사용

키워드: restricted, unrestricted

일부 메일 시스템에서는 RFC 822에서 허용하는 모든 형식의 주소를 처리하는 데 어려움이 있습니다. 이러한 공통된 예로는 잘못된 구성 파일을 갖는 sendmail 기반 메일 프로그램이 있습니다. 따옴표가 있는 로컬 부분 또는 메일함 사양이 문제의 원인이 되는 경우가 많습니다.

"smith, ned"@siroe.com

이러한 것이 문제의 주된 원인이며 RFC 1137에는 이러한 문제를 해결하기 위한 방법론이 나와 있습니다. 기본적인 방법은 주소에서 따옴표를 제거한 다음 따옴표가 필요한 문자를 atom에 허용된 문자로 매핑하는 변환을 적용하는 것입니다. 여기에 사용되는 atom에 대한 정의는 RFC 822를 참조하십시오. 예를 들면 선행 주소는 다음과 같습니다.

smith#m#_ned@siroe.com

restricted 채널 키워드는 채널이 이 인코딩을 필요로 하는 시스템에 연결됨을 MTA에 알려줍니다. 그러면 MTA는 채널에 메시지가 기록될 때 헤더와 봉투 주소 모두에서 따옴표가 있는 로컬 부분을 인코딩합니다. 채널의 받는 주소는 자동으로 디코딩됩니다. unrestricted 키워드는 MTA에 RFC 1137 인코딩 및 디코딩을 수행하지 않도록 지시합니다. 기본값은 unrestricted 키워드입니다.

따옴표가 있는 로컬 부분을 적용할 수 없는 시스템에 연결하는 채널에는 restricted 키워드를 적용해야 합니다. 따옴표가 있는 로컬 부분을 실제로 생성하는 채널에는 이 키워드를 적용할 수 없습니다. 그런 주소를 생성할 수 있는 채널은 해당 주소를 처리할 수 있다고 가정합니다.

12.6.11 Return-path: 헤더 행 생성

키워드: addreturnpath, noaddreturnpath

일반적으로 Return-path: 헤더 행을 추가하는 것은 최종 전달을 수행하는 채널에서 담당합니다. ims-ms 채널과 같은 일부 채널의 경우 채널에서 Return-path: 헤더를 추가하는 것보다 MTA에서 추가하는 것이 더 효과적입니다. addreturnpath 키워드는 Return-path: 헤더가 이 채널의 대기열에 포함될 때 이 경로를 추가합니다.

12.6.12 봉투의 To: 및 From: 주소에서 Received: 헤더 행 구성

키워드: receivedfor, noreceivedfor, receivedfrom, noreceivedfrom

receivedfor 키워드는 메시지의 주소가 한 명의 봉투 수신자로만 지정된 경우 해당 봉투의 To: 주소를 Received: 헤더 행에 포함하도록 MTA에 지시합니다. 기본값은 receivedfor 키워드입니다. noreceivedfor 키워드는 봉투 주소 정보를 포함하지 않고 Received: 헤더 행을 구성하도록 MTA에 지시합니다.

receivedfrom 키워드는 특정 종류의 메일 목록 확장으로 인해 MTA에서 봉투의 From: 주소를 변경한 경우, 받는 메시지에 대한 Received: 헤더 행을 구성할 때 원래의 From: 주소를 포함하도록 MTA에 지시합니다. 기본값은 receivedfrom입니다. noreceivedfrom 키워드는 원래 From: 주소를 포함하지 않고 Received: 헤더 행을 구성하도록 MTA에 지시합니다.

12.6.13 주소 헤더 행의 주석 처리

키워드: commentinc, commentmap, commentomit, commentstrip, commenttotal, sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, sourcecommenttotal

MTA는 필요한 경우에만 헤더 행의 내용을 해석합니다. 그러나 주소를 포함하는 모든 등록된 헤더 행의 구문을 분석하여 축약형 주소를 제거한 다음 올바른 주소로 변환해야 합니다. 이 프로세스 중에 헤더 행을 다시 작성할 때 주석(괄호로 묶인 문자열)을 추출하여 수정하거나 제외할 수 있습니다.

이 동작은 commentinc, commentmap, commentomit, commentstrip 및 commenttotal 키워드를 사용하여 제어합니다. commentinc 키워드는 헤더 행에 주석을 유지하도록 MTA에 지시하는 기본값입니다. commentomit 키워드는 To:, From:, Cc: 헤더 행과 같은 주소 지정 헤더에서 주석을 제거하도록 MTA에 지시합니다.

commenttotal 키워드는 Received: 헤더 행을 제외한 모든 헤더 행에서 주석을 제거하도록 MTA에 지시합니다. 이 키워드는 대부분 유용하지 않거나 권장되지 않습니다. commentstrip은 모든 주석 필드에서 nonatomic 문자를 제거하도록 MTA에 지시합니다. commentmap 키워드는 COMMENT_STRINGS매핑 테이블을 통해 주석 문자열을 실행합니다.

소스 채널에서 이 동작은 sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip 및 sourcecommenttotal 키워드에 의해 제어됩니다. sourcecommentinc 키워드는 헤더 행에 주석을 유지하도록 MTA에 지시하는 기본값입니다. sourcecommentomit 키워드는 To:, From:, Cc:, From:, Cc: 등과 같은 주소 지정 헤더)에서 주석을 제거하도록 MTA에 지시합니다. sourcecommenttotal 키워드는 Received: 헤더를 제외한 모든 헤더에서 주석을 제거하도록 MTA에 지시합니다. 따라서, 이 키워드는 대부분 유용하지 않거나 권장되지 않습니다. 마지막으로 sourcecommentstrip 키워드는 모든 주석 필드에서 nonatomic 문자를 스트라이프하도록 MTA에 지시합니다. sourcecommentmap 키워드는 소스 채널을 통해 주석 문자열을 실행합니다.

이러한 키워드는 모든 채널에 적용될 수 있습니다.

COMMENT_STRINGS 매핑 테이블의 구문은 다음과 같습니다.

(comment_text) | address

항목 템플리트가 $Y 플래그를 설정하는 경우 원래 주석이 지정된 텍스트(괄호로 묶임)로 변경됩니다.

12.6.14 주소 헤더 행에서 개인 이름 처리

키워드: personalinc, personalmap, personalomit, personalstrip, sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, sourcepersonalstrip

다시 쓰기 프로세스 중에 주소를 포함하는 모든 등록된 헤더 행의 구문을 분석하여 축약형 주소를 제거한 다음 올바른 주소로 변환해야 합니다. 이 프로세스 중에 헤더 행을 다시 작성할 때 개인 이름(대괄호로 구분된 주소 앞의 문자열)을 추출하여 선택적으로 수정하거나 제외할 수 있습니다.

이 동작은 personalinc, personalmap, personalomit 및 personalstrip 키워드를 사용하여 제어합니다. personalinc 키워드는 헤더에 개인 이름을 유지하도록 MTA에 지시하는 기본값입니다. personalomit 키워드는 모든 개인 이름을 제거하도록 MTA에 지시합니다. personalstrip 키워드는 모든 개인 이름 필드에서 nonatomic 문자를 제거하도록 MTA에 지시합니다. personalmap 키워드는 PERSONAL_NAMES 매핑 테이블을 통해 개인 이름을 실행하도록 MTA에 지시합니다.

소스 채널에서 이 동작은 sourcepersonalinc, sourcepersonalmap, sourcepersonalomit 또는 sourcepersonalstrip 키워드에 의해 제어됩니다. sourcepersonalinc 키워드는 헤더에 개인 이름을 유지하도록 MTA에 지시하는 기본값입니다. sourcepersonalomit 키워드는 모든 개인 이름을 제거하도록 MTA에 지시합니다. 마지막으로 sourcepersonalstrip은 모든 개인 이름 필드에서 nonatomic 문자를 제거하도록 MTA에 지시합니다. sourcepersonalmap 키워드는 소스 채널을 통해 개인 이름을 실행하도록 MTA에 지시합니다.

이러한 키워드는 모든 채널에 적용될 수 있습니다.

PERSONAL_NAMES 매핑 테이블 검사 구문은 다음과 같습니다.

personal_name | address

템플리트에 $Y 플래그를 설정하면 원래의 개인 이름이 지정된 텍스트로 변경됩니다.

12.6.15 별칭 파일 및 별칭 데이터베이스 검사 지정

키워드: aliaslocal

일반적으로 로컬 채널(UNIX의 l 채널)에 다시 작성된 주소만 별칭 파일과 별칭 데이터베이스에서 조회됩니다. aliaslocal 키워드를 채널에 배치하여 별칭 파일과 별칭 데이터베이스에서 해당 채널에 다시 작성된 주소를 조회할 수도 있습니다. 만든 조회 검사의 정확한 형식은 ALIAS_DOMAINS 옵션에 의해 제어됩니다.

12.6.16 하위 주소 처리

키워드: subaddressexact, subaddressrelaxed, subaddresswild

하위 주소의 개념 관련 배경으로 원시 및 ims-ms 채널은 주소의 로컬 부분(메일함 부분)에서 + 문자를 해석합니다. name+subaddress@domain 형식 주소에서 MTA는 더하기(+) 문자 뒤의 메일함 부분을 하위 주소로 간주합니다. 원시 채널은 하위 주소를 추가 정보로 취급하고 해당 하위 주소에 관계 없이 계정 이름에 실제로 전달합니다. ims-ms 채널은 하위 주소를 전달할 폴더 이름으로 해석합니다.

하위 주소는 로컬 채널(UNIX의 L 채널)에 의한 별칭 조회, aliaslocal 키워드로 표시한 채널에 의한 별칭 조회, 디렉토리 채널에 의한 메일함 조회 등에도 영향을 미칩니다. 그런 일치를 위해 정확한 하위 주소 처리를 구성할 수 있습니다. 주소를 항목과 비교할 경우 MTA는 항상 하위 주소를 포함한 전체 메일함에서 정확한 일치를 먼저 검사합니다. 그런 다음 MTA가 추가 검사를 수행하는지 여부를 구성할 수 있습니다.

subaddressexact 키워드는 항목 일치 중에 특수 하위 주소 처리를 수행하지 않도록 MTA에 지시합니다. 하위 주소를 포함하여 전체 메일함이 항목과 일치해야 별칭이 일치하는 것으로 간주됩니다. 추가 비교(와일드카드 비교 또는 하위 주소를 제외한 비교)가 수행되지 않습니다. subaddresswild 키워드는 전체 하위 주소를 포함한 정확한 일치를 조사한 다음 name+* 형식 항목을 조사하도록 MTA에 지시합니다. subaddressrelaxed 키워드는 정확한 일치를 조사하고 name+* 형식 일치를 조사한 다음 이름 부분에 대해서만 일치를 조사하도록 MTA에 지시합니다. subaddressrelaxed를 사용하면 다음 형식의 별칭 항목이 name 또는 name+subaddress와 일치되고, 일반 이름이 새 이름으로 변환되며, name+subaddress가 newname+subaddress로 변환됩니다. 기본값은 subaddressrelaxed 키워드입니다.

name:   newname+*

따라서 subaddresswild 키워드 또는 subaddressrelaxed 키워드는 별칭 또는 디렉토리 채널이 사용 중이지만 임의의 하위 주소를 사용하여 주소가 지정된 메일을 받으려는 경우에 유용할 수 있습니다. 이러한 키워드를 사용하면 주소에서 단일 하위 주소 변형마다 별도의 항목을 둘 필요가 없습니다.

이러한 키워드는 로컬 채널(UNIX의 L 채널) 또는 aliaslocal 키워드로 표시한 채널에만 적용됩니다.

표준 Messaging Server 구성은 실제로 subaddressrelaxed 동작을 하는 L 채널에서 중계됩니다(기본적으로 다른 키워드를 명시하지 않은 경우).

12.6.17 채널별 다시 쓰기 규칙 검사 사용

키워드: rules, norules

rules 키워드는 이 채널에 대해 채널별 다시 쓰기 규칙 검사를 실행하도록 MTA에 지시합니다. 기본값입니다. norules 키워드는 이 채널을 검사하지 않도록 MTA에 지시합니다. 이 두 키워드는 일반적으로 디버깅하는 데 사용되고 실제 응용 프로그램에서는 거의 사용되지 않습니다.

12.6.18 소스 경로 제거

키워드: dequeue_removeroute

dequeue_removeroute 키워드는 메시지를 대기열에서 제거할 때 소스 경로를 봉투의 To: 주소에서 제거합니다. 이 키워드는 현재 tcp-* 채널에서만 구현됩니다. 또한, 소스 경로를 올바르게 처리하지 못하는 시스템에 메시지를 전송할 때 유용합니다.

12.6.19 반드시 별칭을 통해 주소 지정

키워드: viaaliasoptional, viaaliasrequired

viaaliasrequired는 채널과 일치하는 최종 수신자 주소를 별칭을 통해 생성해야 함을 지정합니다. 최종 수신자 주소는 별칭 확장(해당하는 경우)이 수행된 이후의 일치를 참조합니다. 주소를 MTA에 수신자 주소로 직접 전달할 수 없습니다. 즉, 주소를 채널에 다시 쓰는 것만으로는 부족합니다. 채널에 다시 쓴 후 별칭을 통해 주소를 확장해야 채널과 일치하는 것으로 간주됩니다.

예를 들어, 로컬 채널에서 viaaliasrequired 키워드를 사용하여 임의의 계정(예: UNIX 시스템에서 임의의 원시 Berkeley 메일함)에 전달하지 못하게 할 수 있습니다.

기본값은 viaaliasoptional이며 별칭을 사용하여 채널과 일치하는 최종 수신자 주소를 생성할 필요가 없음을 의미합니다.

12.6.20 수신자 주소 처리

키워드: acceptalladdresses, acceptvalidaddresses

acceptvalidaddresses가 기본값이며, SMTP 대화 중에 수신자 오류가 즉시 보고되는 MTA 표준 동작에 해당합니다. 채널에 키워드 acceptalladdresses가 지정된 경우 SMTP 대화 중에 모든 수신자 주소가 허용됩니다. 잘못된 주소는 나중에 DSN이 보내집니다.

12.7 헤더 처리 구성

이 절에서는 헤더 및 봉투 정보를 처리하는 키워드에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

• 12.7.1 포함 헤더 다시 쓰기

• 12.7.2 선택한 메시지 헤더 행 제거

• 12.7.3 X-Envelope-to 헤더 행 생성/제거

• 12.7.4 두 자리 또는 네 자리로 날짜 변환

• 12.7.5 날짜의 요일 지정

• 12.7.6 긴 헤더 행 자동 분할

• 12.7.7 헤더 맞춤 및 접기

• 12.7.8 최대 길이 헤더 지정

• 12.7.9 민감도 검사

• 12.7.10 헤더의 기본 언어 설정

• 12.7.11 Message-hash: 헤더 제어

12.7.1 포함 헤더 다시 쓰기

키워드: noinner, inner

필요한 경우에만 헤더 행의 내용을 해석합니다. MIME 메시지는 메시지 내부에 메시지를 포함하는 기능이 있기 때문에 여러 메시지 헤더 집합을 포함할 수 있습니다(메시지/RFC822). MTA는 일반적으로 가장 외부에 있는 메시지 헤더 집합만 해석하고 다시 씁니다. 메시지의 내부 헤더에도 헤더 다시 쓰기를 적용하도록 MTA에 선택적으로 지시할 수 있습니다.

이 동작은 noinner 및 inner 키워드에 의해 제어됩니다. noinner 키워드는 내부 메시지 헤더 행을 다시 쓰지 않도록 MTA에 지시하는 기본값입니다. inner 키워드는 메시지의 구문을 분석하고 내부 헤더를 다시 쓰도록 MTA에 지시합니다. 이러한 키워드는 모든 채널에 적용될 수 있습니다.

12.7.2 선택한 메시지 헤더 행 제거

키워드: headertrim, noheadertrim, headerread, noheaderread, innertrim, noinnertrim

MTA는 메시지에서 선택한 메시지 헤더 행을 잘라내거나 제거하기 위한 채널 단위 기능을 제공합니다. 이 작업은 채널 키워드와 관련 헤더 옵션 파일을 조합하거나 두 가지를 모두 사용하여 수행됩니다. 헤더 옵션 파일 형식에 대해서는 Sun Java System Messaging Server 6.3 Administration Reference의 Header Option Files에 설명되어 있습니다.

headertrim 키워드는 원본 메시지 헤더를 처리한 후에 채널과 연결된 헤더 옵션 파일을 참조하여 해당 대상 채널의 대기열에 포함된 메시지의 헤더를 적절하게 잘라내도록 MTA에 지시합니다. noheadertrim 키워드는 헤더 자르기를 수행하지 않습니다. 기본값은 noheadertrim 키워드입니다.

innertrim 키워드는 내부 메시지 부분(내장된 MESSAGE/RFC822 부분)에서도 헤더 자르기를 수행하도록 MTA에 지시합니다. 기본값인 noinnertrim 키워드는 내부 메시지 부분에서 헤더 자르기를 수행하지 않도록 MTA에 지시합니다.

headerread 키워드는 원본 메시지 헤더를 처리하기 전에 채널과 연결된 헤더 옵션 파일을 참조하여 해당 소스 채널에 의해 대기열에 포함된 메시지의 헤더를 적절하게 잘라내도록 MTA에 지시합니다. 반면에 headertrim 헤더 자르기는 메시지를 처리한 이후에 적용되며 소스 채널이 아니라 대상 채널입니다. noheaderread 키워드는 메시지 대기열이 포함된 헤더 자르기를 수행하지 않습니다. 기본값은 noheaderread입니다.

headeromit 및 headerbottom 키워드와 달리 headertrim 및 headerread 키워드는 모든 채널에 적용될 수 있습니다. 메시지에서 필수 헤더 정보를 스트라이프하면 MTA 작업이 잘못 수행될 수 있습니다. 따라서 제거하거나 제한할 헤더를 선택할 경우 각별히 주의하십시오. 이 기능은 선택한 헤더 행을 제거하거나 제한해야 할 경우를 위해 제공됩니다.

메시지에서 헤더 정보를 스트라이프하면 MTA 작업이 잘못 수행될 수 있습니다. 따라서 제거하거나 제한할 헤더를 선택할 경우 주의하십시오. 이러한 키워드는 선택한 헤더 행을 제거하거나 제한해야 할 경우를 위해 제공됩니다. 헤더 행을 자르거나 제거하기 전에 해당 헤더의 사용법을 이해하고 제거의 함축된 의미를 고려해야 합니다.

headertrim 및 innertrim 키워드의 헤더 옵션 파일에는 채널이 있는 channel_headers.opt 형식 이름과 헤더 옵션 파일이 연결되는 채널 이름이 있습니다. 마찬가지로 headerread 키워드의 헤더 옵션 파일에는 channel_read_headers.opt 형식의 이름이 있습니다. 이러한 파일은 MTA 구성 디렉토리인 instance_root/config/에 저장됩니다.

12.7.3 X-Envelope-to 헤더 행 생성/제거

키워드: x_env_to, nox_env_to

x_env_to 및 nox_env_to 키워드는 특정 채널의 대기열에 포함된 메시지 복사본에서 X-Envelope-to 헤더 행의 생성 또는 억제를 제어합니다. single 키워드로 표시한 채널에서 x_env_to 키워드는 이러한 헤더를 생성하고 nox_env_to 키워드는 대기열에 포함된 메시지에서 해당 헤더를 제거합니다. 기본값은 nox_env_to입니다.

이렇게 하는 것은 거의 의미가 없겠지만, 이제 채널에 single을 설정하지 않고도 x_env_to 키워드를 사용할 수 있습니다.

12.7.4 두 자리 또는 네 자리로 날짜 변환

키워드: datefour, datetwo

원본 RFC 822 사양은 메시지 헤더의 날짜 필드에서 두 자리 연도를 호출합니다. 이 연도 표시는 이후에 RFC 1123에서 네 자리로 변경되었지만, 일부 이전 메일 시스템에서는 네 자리 날짜를 사용할 수 없습니다. 또한, 일부 최신 메일 시스템에서는 두 자리 날짜를 더 이상 받아들일 수 없습니다.

두 형식을 모두 처리할 수 없는 시스템은 표준 위반입니다.

datefour 및 datetwo 키워드는 메시지 헤더 날짜에서 MTA의 연도 필드 처리를 제어합니다. 기본값인 datefour 키워드는 모든 연도 필드를 네 자리로 확장하도록 MTA에 지시합니다. 50보다 작은 두 자리 날짜에는 2000이 추가되고 50보다 큰 값에는 1900이 추가됩니다.