Sun Java System Messaging Server 6.3 관리 설명서

12.8 첨부 파일 및 MIME 처리

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

12.8.1 Encoding 헤더 행 무시

키워드: ignoreencoding, interpretencoding

MTA는 Yes CHARSET-CONVERSION을 사용하여 다양한 비표준 메시지 형식을 MIME으로 변환할 수 있습니다. 특히, RFC 1154 형식에서는 비표준 Encoding: 헤더 행을 사용할 수 있습니다. 일부 게이트웨이에서는 이 헤더 행에 잘못된 정보를 생성하므로 이러한 헤더 행을 무시해야 할 경우도 종종 있습니다. ignoreencoding 키워드는 Encoding: 헤더 행을 무시하도록 MTA에 지시합니다.


주 –

MTA에 CHARSET-CONVERSION이 사용되지 않는 경우 이러한 헤더는 항상 무시됩니다. interpretencoding 키워드가 기본값이며 이 키워드는 Encoding: 헤더 행에 주의하도록 MTA에 지시합니다(다르게 지시되지 않을 경우).


12.8.2 메시지/부분 메시지 자동 조각 모음

키워드: defragment, nodefragment

MIME 표준은 메시지를 더 작은 여러 부분으로 분할하기 위한 메시지/부분 내용 유형을 제공합니다. 이 기능은 크기 제한이 있는 네트워크를 선회하거나 메시지 조각화에서 “검사점 지정” 형식을 제공할 수 있는 불안정한 네트워크를 선회해야 하는 경우에 유용합니다. 그렇게 하면 메시지 전송 중에 네트워크 오류가 발생하더라도 중복된 작업을 줄일 수 있습니다. 메시지가 대상에 도착한 이후에 자동으로 재어셈블할 수 있도록 각 부분에 정보가 포함됩니다.

defragment 채널 키워드 및 조각 모음 채널을 사용하여 MTA에서 메시지를 재어셈블할 수 있습니다. 채널에 defragment 표시가 있는 경우 채널의 대기열에 포함된 부분 메시지가 조각 모음 채널 대기열에 대신 포함됩니다. 모든 부분이 도착하면 메시지가 다시 작성되어 대상 위치로 보내집니다. nodefragment는 이 특수 처리를 사용하지 않습니다. 기본값은 nodefragment 키워드입니다.

12.8.2.1 조각 모음 채널

대상 채널에 defragment 키워드가 있는 경우 메시지는 조각 모음 채널로 라우팅됩니다. 즉, MTA에서 일반적으로 메시지의 대기열에 포함된 대상 채널에 defragment 키워드가 있으면 MTA는 메시지 구조 "내부를 살펴 보고"(MIME 구문 분석) 구조가 MIME 메시지 조각인 것이 확인되면 메시지를 일반 대상 채널로 직접 전송하는 대신 조각 모음 채널로 라우팅합니다.

조각 모음 데이터베이스에는 각 메시지 조각을 받은 호스트를 나타내는 정보를 비롯하여 MTA로 들어오는 메시지 조각에 대한 정보가 포함됩니다. 처음으로 조각을 받고 조각 모음 데이터베이스에 기록하고 나면 같은 조각 모음 데이터베이스를 사용하여 다른 시스템에 수신된 메시지의 다른 모든 부분이 첫 부분을 받은 호스트로 라우팅됩니다. 예를 들면 다음과 같습니다.

  1. message/partial; id=123; part=x는 대상/아웃바운드 채널이 있을 위치에 defragment 키워드가 있기 때문에 호스트 1에 도착한 다음 호스트 1에 있는 조각 모음 채널로 라우팅됩니다.

  2. 호스트 1에 있는 조각 모음 채널에서는 조각 모음 데이터베이스를 검사하여 이 메시지의 다른 부분이 도착했는지 확인합니다. 도착한 다른 부분이 없으면 조각 모음 채널(호스트 1)은 이 부분을 조각 모음 데이터베이스에 넣고 해당 부분이 호스트 1에 있는 것으로 표시합니다.

  3. message/partial; id=123; part=y는 대상/아웃바운드 채널이 있을 위치에 defragment 키워드가 있기 때문에 호스트 2에 도착한 다음 호스트 2에 있는 조각 모음 채널로 라우팅됩니다.

  4. 호스트 2에 있는 조각 모음 채널에서는 조각 모음 데이터베이스를 검사하고 이 메시지의 x 부분이 이미 호스트 1에 저장되어 있는 것을 확인합니다. 조각 모음 채널은 메시지 조각을 호스트 1(소스를 @host1이 포함된 주소로 라우팅)로 전송합니다.

  5. message/partial' id=123; part=y가 호스트 1에 도착하여 조각 모음 채널로 라우팅되면 조각 모음 채널이 실행되고 해당 부분을 데이터베이스에 입력하는 방식으로 계속됩니다.

조각화된 메시지의 나머지 부분은 모두 메시지의 첫 부분(처음 받은 부분, part=1일 필요는 없음)을 받은 호스트로 전달합니다. 메시지는 호스트의 조각 모음 채널에서 재어셈블되며, 조각 모음된 메시지(또는 조각 모음 시간이 초과된 경우 각 조각이 그대로 전송)이 실제 대상 채널로 전송됩니다. 각 메시지의 "첫" 부분을 받는 호스트에 따라 메시지의 조각 모음에 대한 로드 균형 조정이 이루어집니다.

12.8.2.2 조각 모음 채널 보존 시간

메시지는 제한된 시간 동안만 조각 모음 채널 대기열에 보존됩니다. 첫 번째 배달 실패 알림을 보내도록 지정된 시간의 1/2이 경과하면 메시지의 다양한 부분을 재어셈블하지 않고 보냅니다. 이 시간 값 선택은 조각 모음 채널 대기열의 메시지에 대한 배달 실패 알림을 보내지 않게 합니다.

notices 채널 키워드는 배달 실패 알림을 보내기 전에 경과할 수 있는 시간을 제어하며, 부분적으로 보내기 전에 메시지가 보존되는 시간을 제어합니다. notices 키워드 값을 가능한 조각 모음에 대해 메시지를 보존하려는 시간의 2배로 설정합니다. 예를 들어, notices 값을 4로 설정하면 메시지 조각 모음이 2일 동안 보존됩니다.


defragment notices 4 
DEFRAGMENT-DAEMON

12.8.2.3 조각 모음 및 휴가 캐싱에 NFS 기반 파일 시스템 사용

조각 모음 및 휴가 캐싱에는 NFS 기반 파일 시스템이 자주 사용됩니다. 그 용도 중 하나는 여러 MTA 시스템이 모두 동일한 조각 모음 캐시를 공유하도록 지정하여 여러 시스템 사이에서 조각 모음 데이터베이스를 공유하는 것입니다. 이렇게 하려면 각 시스템의 msg-svr-base/config/defragment_cache에서 공유 NFS 디스크 상의 공유 조각 모음 데이터베이스로 사용할 파일로 가는 링크를 만듭니다.

어느 경우에나 휴가 및 조각 모음 캐시에 적절한 NFS 파일 의미를 지원하는 NFS 서버(특히 Solaris NFS와 같이 잠금 요청을 인식하는 서버)를 사용할 수 있습니다. NFS를 사용하는 경우에는 소프트 마운트 옵션을 사용합니다. (기본값은 하드 마운트입니다.)mount timeo 옵션으로 제어되는 시간 초과 값을 비교적 짧게 설정하는 것도 좋습니다( mount_nfs(1M) 설명서 페이지 참조).

NFS 하드 마운트를 사용하는 경우 NFS가 다운되면 여러 시스템의 조각 모음 채널이 중지됩니다. 소프트 마운트를 사용하면 조각 모음 채널이 중지되지 않지만, 조각 모음 캐시를 열 수 없기 때문에 다른 호스트의 조각 모음 채널과 서로 통신할 수 없습니다. 드문 경우이긴 하지만, 모든 메시지의 조각들이 같은 호스트에 처음 도착하는 경우에는 호스트의 조각 모음 채널에서 메시지를 재어셈블하여 계속 전송할 수 있습니다. 그보다는 조각들이 서로 다른 호스트에 도착하여 어셈블되지 않고 관련된 조각 모음 채널의 보존 기간이 만료된 후에 별도의 조각으로 전송될 가능성이 큽니다.

12.8.3 대용량 메시지 자동 조각화

키워드: maxblocks, maxlines

일부 메일 시스템 또는 네트워크 전송 프로그램은 특정 크기 제한을 초과하는 메시지를 처리할 수 없습니다. MTA는 채널 단위로 제한을 적용하는 기능을 제공합니다. 설정된 제한보다 큰 메시지는 여러 개의 작은 메시지로 자동으로 분할(조각화)됩니다. 그런 조각화에 사용되는 내용 유형은 message/partial이며, 동일한 메시지의 각 부분이 서로 연결된 다음 받는 메일 프로그램에 의해 자동으로 재어셈블되도록 고유한 아이디 매개 변수가 추가됩니다.

maxblocksmaxlines 키워드는 자동 조각화가 활성화되는 크기 제한을 적용하는 데 사용됩니다. 이 두 키워드의 뒤에는 단일의 정수 값이 있어야 합니다. maxblocks 키워드는 메시지에 허용되는 최대 블록 수를 지정합니다. MTA 블록은 일반적으로 1024바이트이지만 MTA 옵션 파일의 BLOCK_SIZE 옵션으로 변경할 수 있습니다. maxlines 키워드는 메시지에 허용되는 최대 행 수를 지정합니다. 필요한 경우 이 두 제한을 동시에 적용할 수 있습니다.

메시지 헤더는 메시지 크기에 어느 정도까지는 포함됩니다. 메시지 헤더는 여러 메시지로 분할될 수 없고 지정된 크기 제한을 초과할 수 없기 때문에 메시지 헤더 크기에는 매우 복잡한 기법이 사용됩니다. 이 논리는 MTA 옵션 파일의 MAX_HEADER_BLOCK_USEMAX_HEADER_LINE_USE 옵션에 의해 제어됩니다.

MAX_HEADER_BLOCK_USE를 사용하여 0에서 1까지의 실수를 지정합니다. 기본값은 0.5입니다. 메시지 헤더는 메시지에 소비할 수 있는 총 블록 수(maxblocks 키워드로 지정)에서 이만큼을 차지할 수 있습니다. 메시지 헤더가 긴 경우 MTA는 MAX_HEADER_BLOCK_USEmaxblocks를 곱한 값을 헤더 * MAX_HEADER_BLOCK_USE의 크기로 사용합니다(헤더 크기는 실제 헤더 크기와 maxblocks 중 작은 값).

예를 들어, maxblocks가 10이고 MAX_HEADER_BLOCK_USE가 기본값 0.5인 경우 5블록보다 더 큰 메시지 헤더는 5블록 헤더로 취급되고, 메시지의 크기가 5블록 이하일 경우 조각화되지 않습니다. 값이 0인 경우에는 헤더가 메시지 크기 제한에서 무시됩니다.

값이 1인 경우 헤더에 사용 가능한 최대 크기까지 사용할 수 있습니다. 각 조각은 제한을 초과하는지 여부에 관계 없이 항상 메시지 내용의 한 행 이상을 포함하고 있어야 합니다. MAX_HEADER_LINE_USEmaxlines 키워드와 비슷한 방식으로 동작합니다.

12.8.4 메시지 행 길이 제한 적용

키워드: linelength

SMTP 사양은 최대 1,000바이트를 포함하는 텍스트 행에 사용할 수 있습니다. 보다 엄격한 행 길이 제한이 적용되는 전송 프로그램도 있습니다. linelength 키워드는 채널 단위로 최대 허용 가능한 메시지 행 길이를 제한하는 기법을 제공합니다. 지정된 채널의 대기열에 포함되고 행 길이가 해당 채널에 지정된 제한보다 더 긴 메시지는 자동으로 인코딩됩니다.

MTA에서 사용할 수 있는 다양한 인코딩은 항상 행 길이를 80자 미만으로 줄입니다. 그런 인코딩을 수행한 후 해당 디코딩 필터를 적용하여 원본 메시지를 복구할 수 있습니다.


주 –

인코딩은 행 길이를 80자 미만으로 줄일 수만 있습니다. 80자 미만의 행 길이 값을 지정하면 명시된 제한에 맞는 길이의 행이 생성되지 않을 수 있습니다.


linelength 키워드는 전송을 위해 데이터 인코딩에서 “소프트” 줄 바꿈을 수행하게 합니다. 인코딩은 일반적으로 수신하는 쪽에서 디코딩하여 원래의 “긴” 행을 복구합니다. “하드” 줄 바꿈에 대한 자세한 내용은 표 13–7의 “레코드, 텍스트”를 참조하십시오.

12.8.5 멀티파트 및 Message/RFC822 부분의 cContent-transfer-encoding 필드 해석

키워드: interpretmultipartencoding, ignoremultipartencoding , interpretmessageencoding, ignoremessageencoding

MIME 사양은 멀티파트 또는 message/rfc822 부분에서 7비트, 8비트 및 이진을 제외한 content-transfer-encoding을 사용할 수 없게 합니다. 그러나 일부 에이전트는 이 사양을 위반하고 멀티파트 및 message/rfc822 개체를 인코딩하고 있습니다. 이에 따라 MTA는 그러한 인코딩을 허용 및 제거하는 코드를 갖고 있습니다. 최근, 이와 다른 표준 위반이 등장했는데 quoted-printable 또는 base63 값을 갖는 content-transfer-encoding 필드가 존재하지만 실제로는 그 부분이 인코딩되지 않는 것입니다. MTA에서 그러한 메시지를 디코딩하려고 시도하면 예상하는 대로 빈 메시지가 만들어집니다.

이 문제가 있는 메시지가 많아졌기 때문에 이를 해결하기 위해 두 쌍의 채널 키워드가 새로 추가되었습니다. 즉 멀티파트 및 message/rfc822 부분에서 content-transfer-encoding 필드의 해석을 활성화하거나 비활성화할 수 있습니다. 첫 번째 쌍은 interpretmultipartencodingignoremultipartencoding이며, 두 번째 쌍은 interpretmessageencodingignoremessageencoding입니다. 기본값은 interpretmultipartencodinginterpretmessageencoding 입니다.