메일 서버 배포

Red Hat Enterprise Linux 9

메일 서버 서비스 구성 및 유지 관리

Red Hat Customer Content Services

초록

Red Hat Enterprise Linux에서는 메일 전송 에이전트가 SMTP 서비스로, 메일 전송 에이전트인 Dovecot를 hugepages 및 POP3 서비스로 사용하여 고객 및 내부 사용자에게 안정적이고 안전한 메일 서비스를 제공할 수 있습니다. 두 서비스 모두 서로 통합되어 있으며 LDAP 디렉터리와 같은 중앙 백엔드를 지원하여 계정 데이터를 저장하고 사용자를 인증합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

Jira를 통해 피드백 제출 (등록 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 모음에서 생성 을 클릭합니다.
  3. 요약 필드에 설명 제목을 입력합니다.
  4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. Dovecot CloudEvent 및 POP3 서버 구성 및 유지 관리

Dovecot는 보안에 중점을 두고 있는 고성능 메일 전달 에이전트(knativeA)입니다. skopeo 또는 POP3 호환 이메일 클라이언트를 사용하여 Dovecot 서버에 연결하고 이메일을 읽거나 다운로드할 수 있습니다.

Dovecot의 주요 기능:

  • 설계 및 구현은 보안에 중점을 두고 있습니다.
  • 대규모 환경에서 성능을 개선하기 위해 고가용성을 위한 양방향 복제 지원
  • 호환성상의 이유로 mboxmaildir 도 예외적으로 지원합니다.
  • 손상된 인덱스 파일 수정과 같은 자동 복구 기능
  • CloudEvent 표준 준수
  • CloudEvent 및 POP3 클라이언트의 버그를 우회하는 해결 방법 지원

1.1. PAM 인증을 사용하여 Dovecot 서버 설정

Dovecot는 NSS(Name Service Switch) 인터페이스를 사용자 데이터베이스로, PAM(Pluggable Authentication Modules) 프레임워크를 인증 백엔드로 지원합니다. 이 구성을 통해 Dovecot는 NSS를 통해 서버에서 로컬로 사용 가능한 사용자에게 서비스를 제공할 수 있습니다.

계정의 경우 PAM 인증을 사용합니다.

  • /etc/passwd 파일에서 로컬로 정의됩니다.
  • 원격 데이터베이스에 저장되지만 SSSD(System Security Services Daemon) 또는 기타 NSS 플러그인을 통해 로컬로 사용할 수 있습니다.

1.1.1. Dovecot 설치

dovecot 패키지는 다음을 제공합니다.

  • dovecot 서비스와 이를 유지보수할 유틸리티
  • Dovecot가 필요할 때 시작되는 서비스(예: 인증)
  • 서버 측 메일 필터링과 같은 플러그인
  • /etc/dovecot/ 디렉토리에 있는 설정 파일
  • /usr/share/doc/dovecot/ 디렉토리에 있는 설명서

절차

  • dovecot 패키지를 설치합니다.

    # dnf install dovecot
    참고

    Dovecot가 이미 설치되어 있고 정리된 구성 파일이 필요한 경우 /etc/dovecot/ 디렉토리 이름을 변경하거나 제거해야 합니다. 그런 다음 패키지를 다시 설치합니다. 설정 파일을 제거하지 않으면 dnf reinstall dovecot 명령이 /etc/dovecot/ 의 구성 파일을 재설정하지 않습니다.

1.1.2. Dovecot 서버에서 TLS 암호화 구성

dovecot는 보안 기본 구성을 제공합니다. 예를 들어 TLS는 네트워크를 통해 암호화된 자격 증명 및 데이터를 전송하기 위해 기본적으로 활성화됩니다. Dovecot 서버에서 TLS를 구성하려면 인증서 및 개인 키 파일에 대한 경로만 설정하면 됩니다. 또한 Diffie-Hellman 매개변수를 생성 및 사용하여 완벽한PFS(forward secrecy)를 제공하여 TLS 연결의 보안을 높일 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • 다음 파일이 서버의 나열된 위치에 복사되었습니다.

    • 서버 인증서: /etc/pki/dovecot/certs/server.example.com.crt
    • 개인 키: /etc/pki/dovecot/private/server.example.com.key
    • CA(인증 기관) 인증서: /etc/pki/dovecot/certs/ca.crt
  • 서버 인증서의 Subject DN 필드에 있는 호스트 이름은 서버의 FQDN(정규화된 도메인 이름)과 일치합니다.
  • 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 클라이언트는 확장 마스터 시크릿(Extended Master Secret) 확장을 지원하거나 TLS 1.3을 사용해야 합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.

절차

  1. 개인 키 파일에 대한 보안 권한을 설정합니다.

    # chown root:root /etc/pki/dovecot/private/server.example.com.key
    # chmod 600 /etc/pki/dovecot/private/server.example.com.key
  2. Diffie-Hellman 매개변수를 사용하여 파일을 생성합니다.

    # openssl dhparam -out /etc/dovecot/dh.pem 4096

    서버의 하드웨어 및 엔트로피에 따라 4096비트의 Diffie-Hellman 매개변수를 생성하는 데 몇 분이 걸릴 수 있습니다.

  3. /etc/dovecot/conf.d/10-ssl.conf 파일에서 인증서 및 개인 키 파일의 경로를 설정합니다.

    1. ssl_certssl_key 매개변수를 업데이트하고 서버 인증서 및 개인 키의 경로를 사용하도록 설정합니다.

      ssl_cert = </etc/pki/dovecot/certs/server.example.com.crt
      ssl_key = </etc/pki/dovecot/private/server.example.com.key
    2. ssl_ca 매개변수의 주석을 해제하고 CA 인증서 경로를 사용하도록 설정합니다.

      ssl_ca = </etc/pki/dovecot/certs/ca.crt
    3. ssl_dh 매개변수의 주석을 해제하고 Diffie-Hellman 매개변수 파일의 경로를 사용하도록 설정합니다.

      ssl_dh = </etc/dovecot/dh.pem
    중요

    Dovecot가 파일에서 매개변수 값을 읽으려면 경로는 선행 < 문자로 시작해야 합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/SSL.DovecotConfiguration.txt

1.1.3. 가상 사용자 사용을 위한 Dovecot 준비

기본적으로 Dovecot는 파일 시스템에서 서비스를 사용하는 사용자로 많은 작업을 수행합니다. 그러나 하나의 로컬 사용자를 사용하여 이러한 작업을 수행하도록 Dovecot 백엔드를 구성하면 다음과 같은 몇 가지 이점이 있습니다.

  • dovecot는 사용자 ID(UID)를 사용하는 대신 특정 로컬 사용자로 파일 시스템 작업을 수행합니다.
  • 사용자는 서버에서 로컬로 사용할 수 없습니다.
  • 모든 Webhook 및 사용자별 파일을 하나의 루트 디렉터리에 저장할 수 있습니다.
  • 사용자에게 UID 및 그룹 ID(GID)가 필요하지 않으므로 관리 작업을 줄일 수 있습니다.
  • 서버의 파일 시스템에 액세스할 수 있는 사용자는 이러한 파일에 액세스할 수 없기 때문에 사용자의 속성이나 인덱스를 손상시킬 수 없습니다.
  • 복제를 쉽게 설정할 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.

절차

  1. vmail 사용자를 만듭니다.

    # useradd --home-dir /var/mail/ --shell /usr/sbin/nologin vmail

    dovecot는 나중에 이 사용자를 사용하여boxes를 관리합니다. 보안상의 이유로 dovecot 또는 dovenull 시스템 사용자를 사용하지 마십시오.

  2. /var/mail/ 와 다른 경로를 사용하는 경우 mail_spool_t SELinux 컨텍스트를 설정합니다. 예를 들면 다음과 같습니다.

    # semanage fcontext -a -t mail_spool_t "<path>(/.*)?"
    # restorecon -Rv <path>
  3. vmail 사용자에게 /var/mail/ 에 대한 쓰기 권한을 부여합니다.

    # chown vmail:vmail /var/mail/
    # chmod 700 /var/mail/
  4. /etc/dovecot/conf.d/10-mail.conf 파일에서 mail_location 매개 변수의 주석을 해제하고 이 매개 변수를 copy 형식 및 위치로 설정합니다.

    mail_location = sdbox:/var/mail/%n/

    이 설정으로 다음을 수행합니다.

    • Dovecot는 high-performant dbox box format을 단일 모드에서 사용합니다. 이 모드에서 서비스는 maildir 형식과 유사하게 각 이메일을 별도의 파일에 저장합니다.
    • dovecot는 사용자 이름 경로의 %n 변수를 해결합니다. 이 작업은 각 사용자에게 해당 2.10에 대한 별도의 디렉터리가 있는지 확인하는 데 필요합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/VirtualUsers.txt
  • /usr/share/doc/dovecot/wiki/MailLocation.txt
  • /usr/share/doc/dovecot/wiki/MailboxFormat.dbox.txt
  • /usr/share/doc/dovecot/wiki/Variables.txt

1.1.4. PAM을 Dovecot 인증 백엔드로 사용

기본적으로 Dovecot는 NSS(Name Service Switch) 인터페이스를 사용자 데이터베이스로 사용하고 PAM(Pluggable Authentication Modules) 프레임워크를 인증 백엔드로 사용합니다.

설정을 사용자 정의하여 Dovecot를 사용자 환경에 적용하고 가상 사용자 기능을 사용하여 관리를 단순화합니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • 가상 사용자 기능이 구성됩니다.

절차

  1. /etc/dovecot/conf.d/10-mail.conf 파일에서 first_valid_uid 매개 변수를 업데이트하여 Dovecot에 인증할 수 있는 최소 사용자 ID(UID)를 정의합니다.

    first_valid_uid = 1000

    기본적으로 UID가 1000 개 이상인 사용자는 인증할 수 있습니다. 필요한 경우, Dovecot에서 로그인할 수 있는 가장 높은 UID를 정의하도록 last_valid_uid 매개변수를 설정할 수도 있습니다.

  2. /etc/dovecot/conf.d/auth-system.conf.ext 파일에서 override_fields 매개변수를 userdb 섹션에 다음과 같이 추가합니다.

    userdb {
      driver = passwd
      override_fields = uid=vmail gid=vmail home=/var/mail/%n/
    }

    수정된 값으로 인해 Dovecot는 /etc/passwd 파일에서 이러한 설정을 쿼리하지 않습니다. 따라서 /etc/passwd 에 정의된 홈 디렉터리가 존재할 필요가 없습니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/PasswordDatabase.PAM.txt
  • /usr/share/doc/dovecot/wiki/VirtualUsers.Home.txt

1.1.5. Dovecot 구성 완료

Dovecot를 설치 및 구성한 후 firewalld 서비스에서 필요한 포트를 열고 서비스를 활성화 및 시작합니다. 그런 다음 서버를 테스트할 수 있습니다.

사전 요구 사항

  • Dovecot에서 다음 내용이 구성되어 있습니다.

    • TLS 암호화
    • 인증 백엔드
  • 클라이언트는 CA(인증 기관) 인증서를 신뢰합니다.

절차

  1. 사용자에게 CloudEvent 또는 POP3 서비스만 제공하려면 /etc/dovecot/dovecot.conf 파일에서 protocols 매개변수의 주석을 제거하고 필요한 프로토콜로 설정합니다. 예를 들어, POP3이 필요하지 않은 경우 다음을 설정합니다.

    protocols = imap lmtp

    기본적으로 imap,pop3, lmtp 프로토콜이 활성화됩니다.

  2. 로컬 방화벽에서 포트를 엽니다. 예를 들어, CloudEventS,Forwarded, POP3S 및 POP3 프로토콜의 포트를 여는 경우 다음을 입력합니다.

    # firewall-cmd --permanent --add-service=imaps --add-service=imap --add-service=pop3s --add-service=pop3
    # firewall-cmd --reload
  3. dovecot 서비스를 활성화하고 시작합니다.

    # systemctl enable --now dovecot

검증

  1. Mozilla Thunderbird와 같은 메일 클라이언트를 사용하여 Dovecot에 연결하고 이메일을 읽습니다. 메일 클라이언트 설정은 사용하려는 프로토콜에 따라 다릅니다.

    표 1.1. Dovecot 서버에 대한 연결 설정

    프로토콜포트연결 보안인증 방법

    IMAP

    143

    STARTTLS

    PLAIN[a]

    IMAPS

    993

    SSL/TLS

    PLAIN[a]

    POP3

    110

    STARTTLS

    PLAIN[a]

    POP3S

    995

    SSL/TLS

    PLAIN[a]

    [a] 클라이언트는 TLS 연결을 통해 암호화된 데이터를 전송합니다. 따라서 인증 정보가 공개되지 않습니다.

    기본적으로 Dovecot는 TLS가 없는 연결에서 일반 텍스트 인증을 허용하지 않으므로 이 테이블에는 암호화되지 않은 연결의 설정이 나열되지 않습니다.

  2. 기본값이 아닌 값을 사용하여 구성 설정을 표시합니다.

    # doveconf -n

추가 리소스

  • firewall-cmd(1) 매뉴얼 페이지

1.2. LDAP 인증을 사용하여 Dovecot 서버 설정

인프라에서 LDAP 서버를 사용하여 계정을 저장하는 경우 Dovecot 사용자를 인증할 수 있습니다. 이 경우 디렉토리에서 계정을 중앙에서 관리하고, 사용자는 Dovecot 서버의 파일 시스템에 대한 로컬 액세스 권한이 필요하지 않습니다.

중앙 집중식으로 관리되는 계정도 복제를 통해 여러 개의 Dovecot 서버를 설정할 계획의 경우 benefit가 됩니다.Donently-managed accounts are also a benefit if you plan to set up multiple Dovecot servers with replication.

1.2.1. Dovecot 설치

dovecot 패키지는 다음을 제공합니다.

  • dovecot 서비스와 이를 유지보수할 유틸리티
  • Dovecot가 필요할 때 시작되는 서비스(예: 인증)
  • 서버 측 메일 필터링과 같은 플러그인
  • /etc/dovecot/ 디렉토리에 있는 설정 파일
  • /usr/share/doc/dovecot/ 디렉토리에 있는 설명서

절차

  • dovecot 패키지를 설치합니다.

    # dnf install dovecot
    참고

    Dovecot가 이미 설치되어 있고 정리된 구성 파일이 필요한 경우 /etc/dovecot/ 디렉토리 이름을 변경하거나 제거해야 합니다. 그런 다음 패키지를 다시 설치합니다. 설정 파일을 제거하지 않으면 dnf reinstall dovecot 명령이 /etc/dovecot/ 의 구성 파일을 재설정하지 않습니다.

1.2.2. Dovecot 서버에서 TLS 암호화 구성

dovecot는 보안 기본 구성을 제공합니다. 예를 들어 TLS는 네트워크를 통해 암호화된 자격 증명 및 데이터를 전송하기 위해 기본적으로 활성화됩니다. Dovecot 서버에서 TLS를 구성하려면 인증서 및 개인 키 파일에 대한 경로만 설정하면 됩니다. 또한 Diffie-Hellman 매개변수를 생성 및 사용하여 완벽한PFS(forward secrecy)를 제공하여 TLS 연결의 보안을 높일 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • 다음 파일이 서버의 나열된 위치에 복사되었습니다.

    • 서버 인증서: /etc/pki/dovecot/certs/server.example.com.crt
    • 개인 키: /etc/pki/dovecot/private/server.example.com.key
    • CA(인증 기관) 인증서: /etc/pki/dovecot/certs/ca.crt
  • 서버 인증서의 Subject DN 필드에 있는 호스트 이름은 서버의 FQDN(정규화된 도메인 이름)과 일치합니다.
  • 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 클라이언트는 확장 마스터 시크릿(Extended Master Secret) 확장을 지원하거나 TLS 1.3을 사용해야 합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.

절차

  1. 개인 키 파일에 대한 보안 권한을 설정합니다.

    # chown root:root /etc/pki/dovecot/private/server.example.com.key
    # chmod 600 /etc/pki/dovecot/private/server.example.com.key
  2. Diffie-Hellman 매개변수를 사용하여 파일을 생성합니다.

    # openssl dhparam -out /etc/dovecot/dh.pem 4096

    서버의 하드웨어 및 엔트로피에 따라 4096비트의 Diffie-Hellman 매개변수를 생성하는 데 몇 분이 걸릴 수 있습니다.

  3. /etc/dovecot/conf.d/10-ssl.conf 파일에서 인증서 및 개인 키 파일의 경로를 설정합니다.

    1. ssl_certssl_key 매개변수를 업데이트하고 서버 인증서 및 개인 키의 경로를 사용하도록 설정합니다.

      ssl_cert = </etc/pki/dovecot/certs/server.example.com.crt
      ssl_key = </etc/pki/dovecot/private/server.example.com.key
    2. ssl_ca 매개변수의 주석을 해제하고 CA 인증서 경로를 사용하도록 설정합니다.

      ssl_ca = </etc/pki/dovecot/certs/ca.crt
    3. ssl_dh 매개변수의 주석을 해제하고 Diffie-Hellman 매개변수 파일의 경로를 사용하도록 설정합니다.

      ssl_dh = </etc/dovecot/dh.pem
    중요

    Dovecot가 파일에서 매개변수 값을 읽으려면 경로는 선행 < 문자로 시작해야 합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/SSL.DovecotConfiguration.txt

1.2.3. 가상 사용자 사용을 위한 Dovecot 준비

기본적으로 Dovecot는 파일 시스템에서 서비스를 사용하는 사용자로 많은 작업을 수행합니다. 그러나 하나의 로컬 사용자를 사용하여 이러한 작업을 수행하도록 Dovecot 백엔드를 구성하면 다음과 같은 몇 가지 이점이 있습니다.

  • dovecot는 사용자 ID(UID)를 사용하는 대신 특정 로컬 사용자로 파일 시스템 작업을 수행합니다.
  • 사용자는 서버에서 로컬로 사용할 수 없습니다.
  • 모든 Webhook 및 사용자별 파일을 하나의 루트 디렉터리에 저장할 수 있습니다.
  • 사용자에게 UID 및 그룹 ID(GID)가 필요하지 않으므로 관리 작업을 줄일 수 있습니다.
  • 서버의 파일 시스템에 액세스할 수 있는 사용자는 이러한 파일에 액세스할 수 없기 때문에 사용자의 속성이나 인덱스를 손상시킬 수 없습니다.
  • 복제를 쉽게 설정할 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.

절차

  1. vmail 사용자를 만듭니다.

    # useradd --home-dir /var/mail/ --shell /usr/sbin/nologin vmail

    dovecot는 나중에 이 사용자를 사용하여boxes를 관리합니다. 보안상의 이유로 dovecot 또는 dovenull 시스템 사용자를 사용하지 마십시오.

  2. /var/mail/ 와 다른 경로를 사용하는 경우 mail_spool_t SELinux 컨텍스트를 설정합니다. 예를 들면 다음과 같습니다.

    # semanage fcontext -a -t mail_spool_t "<path>(/.*)?"
    # restorecon -Rv <path>
  3. vmail 사용자에게 /var/mail/ 에 대한 쓰기 권한을 부여합니다.

    # chown vmail:vmail /var/mail/
    # chmod 700 /var/mail/
  4. /etc/dovecot/conf.d/10-mail.conf 파일에서 mail_location 매개 변수의 주석을 해제하고 이 매개 변수를 copy 형식 및 위치로 설정합니다.

    mail_location = sdbox:/var/mail/%n/

    이 설정으로 다음을 수행합니다.

    • Dovecot는 high-performant dbox box format을 단일 모드에서 사용합니다. 이 모드에서 서비스는 maildir 형식과 유사하게 각 이메일을 별도의 파일에 저장합니다.
    • dovecot는 사용자 이름 경로의 %n 변수를 해결합니다. 이 작업은 각 사용자에게 해당 2.10에 대한 별도의 디렉터리가 있는지 확인하는 데 필요합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/VirtualUsers.txt
  • /usr/share/doc/dovecot/wiki/MailLocation.txt
  • /usr/share/doc/dovecot/wiki/MailboxFormat.dbox.txt
  • /usr/share/doc/dovecot/wiki/Variables.txt

1.2.4. LDAP를 Dovecot 인증 백엔드로 사용

LDAP 디렉터리의 사용자는 일반적으로 디렉터리 서비스에 자신을 인증할 수 있습니다. dovecot는 이 서비스를 사용하여 Manila 및 POP3 서비스에 로그인할 때 사용자를 인증할 수 있습니다. 이 인증 방법은 다음과 같은 다양한 이점을 제공합니다.

  • 관리자는 디렉터리에서 사용자를 중앙에서 관리할 수 있습니다.
  • LDAP 계정에는 특별한 속성이 필요하지 않습니다. LDAP 서버에만 인증할 수 있어야 합니다. 결과적으로 이 방법은 LDAP 서버에서 사용되는 암호 스토리지 스키마와는 독립적입니다.
  • NSS(Name Service Switch) 인터페이스와PAM(Pluggable Authentication Modules) 프레임워크를 통해 서버에서 로컬에서 사용할 수 없습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • 가상 사용자 기능이 구성됩니다.
  • LDAP 서버에 대한 연결은 TLS 암호화를 지원합니다.
  • Dovecot 서버의 RHEL은 LDAP 서버의 CA(인증 기관) 인증서를 신뢰합니다.
  • 사용자가 LDAP 디렉터리의 다른 트리에 저장된 경우 디렉터리를 검색하는 데 Dovecot 전용 LDAP 계정이 있습니다. 이 계정에는 다른 사용자의 고유 이름(DN)을 검색할 수 있는 권한이 필요합니다.
  • MariaDB 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 이 Dovecot 서버는 확장 마스터 시크릿(ECDSA) 확장을 지원하거나 TLS 1.3을 사용합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.

절차

  1. /etc/dovecot/conf.d/10-auth.conf 파일에서 인증 백엔드를 구성합니다.

    1. 주석 처리에 auth-*.conf.ext 인증 백엔드 구성 파일에 대한 설명이 포함되어 있습니다. 예를 들면 다음과 같습니다.

      #!include auth-system.conf.ext
    2. 다음 줄의 주석을 해제하여 LDAP 인증을 활성화합니다.

      !include auth-ldap.conf.ext
  2. /etc/dovecot/conf.d/auth-ldap.conf.ext 파일을 편집하고 다음과 같이 override_fields 매개변수를 userdb 섹션에 추가합니다.

    userdb {
      driver = ldap
      args = /etc/dovecot/dovecot-ldap.conf.ext
      override_fields = uid=vmail gid=vmail home=/var/mail/%n/
    }

    수정된 값으로 인해 Dovecot는 LDAP 서버에서 이러한 설정을 쿼리하지 않습니다. 따라서 이러한 속성도 존재할 필요가 없습니다.

  3. 다음 설정으로 /etc/dovecot/dovecot-ldap.conf.ext 파일을 만듭니다.

    1. LDAP 구조에 따라 다음 중 하나를 구성합니다.

      • 사용자가 LDAP 디렉터리의 다른 트리에 저장된 경우 동적 DN 조회를 구성합니다.

        dn = cn=dovecot_LDAP,dc=example,dc=com
        dnpass = password
        pass_filter = (&(objectClass=posixAccount)(uid=%n))

        dovecot는 지정된 DN, password 및 filter를 사용하여 디렉터리에서 인증 사용자의 DN을 검색합니다. 이 검색에서 Dovecot는 필터의 %n 을 사용자 이름으로 교체합니다. LDAP 검색에서는 하나의 결과만 반환해야 합니다.

      • 모든 사용자가 특정 항목에 저장된 경우 DN 템플릿을 구성합니다.

        auth_bind_userdn = cn=%n,ou=People,dc=example,dc=com
    2. LDAP 서버에 인증 바인딩을 활성화하여 Dovecot 사용자를 확인합니다.

      auth_bind = yes
    3. URL을 LDAP 서버로 설정합니다.

      uris = ldaps://LDAP-srv.example.com

      보안상의 이유로 LDAP 프로토콜을 통해 LDAPS 또는ECDHE TLS 명령을 사용하여 암호화된 연결만 사용하십시오. 후자의 경우 설정에 tls = yes 를 추가합니다.

      작업 인증서 검증을 위해 LDAP 서버의 호스트 이름이 TLS 인증서에 사용된 호스트 이름과 일치해야 합니다.

    4. LDAP 서버의 TLS 인증서 확인을 활성화합니다.

      tls_require_cert = hard
    5. 사용자 검색을 시작할 DN으로 기본 DN을 설정합니다.

      base = ou=People,dc=example,dc=com
    6. 검색 범위를 설정합니다.

      scope = onelevel

      dovecot는 지정된 기본 DN에서만 onelevel 범위로, 하위 트리에서 하위 트리 범위를 사용하여 검색합니다.

  4. /etc/dovecot/dovecot-ldap.conf.ext 파일에 보안 권한을 설정합니다.

    # chown root:root /etc/dovecot/dovecot-ldap.conf.ext
    # chmod 600 /etc/dovecot/dovecot-ldap.conf.ext

추가 리소스

  • /usr/share/doc/dovecot/example-config/dovecot-ldap.conf.ext
  • /usr/share/doc/dovecot/wiki/UserDatabase.Static.txt
  • /usr/share/doc/dovecot/wiki/AuthDatabase.LDAP.txt
  • /usr/share/doc/dovecot/wiki/AuthDatabase.LDAP.AuthBinds.txt
  • /usr/share/doc/dovecot/wiki/AuthDatabase.LDAP.PasswordLookups.txt

1.2.5. Dovecot 구성 완료

Dovecot를 설치 및 구성한 후 firewalld 서비스에서 필요한 포트를 열고 서비스를 활성화 및 시작합니다. 그런 다음 서버를 테스트할 수 있습니다.

사전 요구 사항

  • Dovecot에서 다음 내용이 구성되어 있습니다.

    • TLS 암호화
    • 인증 백엔드
  • 클라이언트는 CA(인증 기관) 인증서를 신뢰합니다.

절차

  1. 사용자에게 CloudEvent 또는 POP3 서비스만 제공하려면 /etc/dovecot/dovecot.conf 파일에서 protocols 매개변수의 주석을 제거하고 필요한 프로토콜로 설정합니다. 예를 들어, POP3이 필요하지 않은 경우 다음을 설정합니다.

    protocols = imap lmtp

    기본적으로 imap,pop3, lmtp 프로토콜이 활성화됩니다.

  2. 로컬 방화벽에서 포트를 엽니다. 예를 들어, CloudEventS,Forwarded, POP3S 및 POP3 프로토콜의 포트를 여는 경우 다음을 입력합니다.

    # firewall-cmd --permanent --add-service=imaps --add-service=imap --add-service=pop3s --add-service=pop3
    # firewall-cmd --reload
  3. dovecot 서비스를 활성화하고 시작합니다.

    # systemctl enable --now dovecot

검증

  1. Mozilla Thunderbird와 같은 메일 클라이언트를 사용하여 Dovecot에 연결하고 이메일을 읽습니다. 메일 클라이언트 설정은 사용하려는 프로토콜에 따라 다릅니다.

    표 1.2. Dovecot 서버에 대한 연결 설정

    프로토콜포트연결 보안인증 방법

    IMAP

    143

    STARTTLS

    PLAIN[a]

    IMAPS

    993

    SSL/TLS

    PLAIN[a]

    POP3

    110

    STARTTLS

    PLAIN[a]

    POP3S

    995

    SSL/TLS

    PLAIN[a]

    [a] 클라이언트는 TLS 연결을 통해 암호화된 데이터를 전송합니다. 따라서 인증 정보가 공개되지 않습니다.

    기본적으로 Dovecot는 TLS가 없는 연결에서 일반 텍스트 인증을 허용하지 않으므로 이 테이블에는 암호화되지 않은 연결의 설정이 나열되지 않습니다.

  2. 기본값이 아닌 값을 사용하여 구성 설정을 표시합니다.

    # doveconf -n

추가 리소스

  • firewall-cmd(1) 매뉴얼 페이지

1.3. MariaDB SQL 인증을 사용하여 Dovecot 서버 설정

사용자 및 암호를 MariaDB SQL 서버에 저장하는 경우 Dovecot를 사용자 데이터베이스 및 인증 백엔드로 사용하도록 구성할 수 있습니다. 이 구성을 사용하면 데이터베이스에서 계정을 중앙에서 관리하고 사용자는 Dovecot 서버의 파일 시스템에 대한 로컬 액세스 권한이 없습니다.

중앙 집중식 관리 계정을 사용하면 복제를 통해 여러 개의 Dovecot 서버를 설정하여 kdump를 고가용성으로 만들 계획도 누릴 수 있습니다.

1.3.1. Dovecot 설치

dovecot 패키지는 다음을 제공합니다.

  • dovecot 서비스와 이를 유지보수할 유틸리티
  • Dovecot가 필요할 때 시작되는 서비스(예: 인증)
  • 서버 측 메일 필터링과 같은 플러그인
  • /etc/dovecot/ 디렉토리에 있는 설정 파일
  • /usr/share/doc/dovecot/ 디렉토리에 있는 설명서

절차

  • dovecot 패키지를 설치합니다.

    # dnf install dovecot
    참고

    Dovecot가 이미 설치되어 있고 정리된 구성 파일이 필요한 경우 /etc/dovecot/ 디렉토리 이름을 변경하거나 제거해야 합니다. 그런 다음 패키지를 다시 설치합니다. 설정 파일을 제거하지 않으면 dnf reinstall dovecot 명령이 /etc/dovecot/ 의 구성 파일을 재설정하지 않습니다.

1.3.2. Dovecot 서버에서 TLS 암호화 구성

dovecot는 보안 기본 구성을 제공합니다. 예를 들어 TLS는 네트워크를 통해 암호화된 자격 증명 및 데이터를 전송하기 위해 기본적으로 활성화됩니다. Dovecot 서버에서 TLS를 구성하려면 인증서 및 개인 키 파일에 대한 경로만 설정하면 됩니다. 또한 Diffie-Hellman 매개변수를 생성 및 사용하여 완벽한PFS(forward secrecy)를 제공하여 TLS 연결의 보안을 높일 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • 다음 파일이 서버의 나열된 위치에 복사되었습니다.

    • 서버 인증서: /etc/pki/dovecot/certs/server.example.com.crt
    • 개인 키: /etc/pki/dovecot/private/server.example.com.key
    • CA(인증 기관) 인증서: /etc/pki/dovecot/certs/ca.crt
  • 서버 인증서의 Subject DN 필드에 있는 호스트 이름은 서버의 FQDN(정규화된 도메인 이름)과 일치합니다.
  • 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 클라이언트는 확장 마스터 시크릿(Extended Master Secret) 확장을 지원하거나 TLS 1.3을 사용해야 합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.

절차

  1. 개인 키 파일에 대한 보안 권한을 설정합니다.

    # chown root:root /etc/pki/dovecot/private/server.example.com.key
    # chmod 600 /etc/pki/dovecot/private/server.example.com.key
  2. Diffie-Hellman 매개변수를 사용하여 파일을 생성합니다.

    # openssl dhparam -out /etc/dovecot/dh.pem 4096

    서버의 하드웨어 및 엔트로피에 따라 4096비트의 Diffie-Hellman 매개변수를 생성하는 데 몇 분이 걸릴 수 있습니다.

  3. /etc/dovecot/conf.d/10-ssl.conf 파일에서 인증서 및 개인 키 파일의 경로를 설정합니다.

    1. ssl_certssl_key 매개변수를 업데이트하고 서버 인증서 및 개인 키의 경로를 사용하도록 설정합니다.

      ssl_cert = </etc/pki/dovecot/certs/server.example.com.crt
      ssl_key = </etc/pki/dovecot/private/server.example.com.key
    2. ssl_ca 매개변수의 주석을 해제하고 CA 인증서 경로를 사용하도록 설정합니다.

      ssl_ca = </etc/pki/dovecot/certs/ca.crt
    3. ssl_dh 매개변수의 주석을 해제하고 Diffie-Hellman 매개변수 파일의 경로를 사용하도록 설정합니다.

      ssl_dh = </etc/dovecot/dh.pem
    중요

    Dovecot가 파일에서 매개변수 값을 읽으려면 경로는 선행 < 문자로 시작해야 합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/SSL.DovecotConfiguration.txt

1.3.3. 가상 사용자 사용을 위한 Dovecot 준비

기본적으로 Dovecot는 파일 시스템에서 서비스를 사용하는 사용자로 많은 작업을 수행합니다. 그러나 하나의 로컬 사용자를 사용하여 이러한 작업을 수행하도록 Dovecot 백엔드를 구성하면 다음과 같은 몇 가지 이점이 있습니다.

  • dovecot는 사용자 ID(UID)를 사용하는 대신 특정 로컬 사용자로 파일 시스템 작업을 수행합니다.
  • 사용자는 서버에서 로컬로 사용할 수 없습니다.
  • 모든 Webhook 및 사용자별 파일을 하나의 루트 디렉터리에 저장할 수 있습니다.
  • 사용자에게 UID 및 그룹 ID(GID)가 필요하지 않으므로 관리 작업을 줄일 수 있습니다.
  • 서버의 파일 시스템에 액세스할 수 있는 사용자는 이러한 파일에 액세스할 수 없기 때문에 사용자의 속성이나 인덱스를 손상시킬 수 없습니다.
  • 복제를 쉽게 설정할 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.

절차

  1. vmail 사용자를 만듭니다.

    # useradd --home-dir /var/mail/ --shell /usr/sbin/nologin vmail

    dovecot는 나중에 이 사용자를 사용하여boxes를 관리합니다. 보안상의 이유로 dovecot 또는 dovenull 시스템 사용자를 사용하지 마십시오.

  2. /var/mail/ 와 다른 경로를 사용하는 경우 mail_spool_t SELinux 컨텍스트를 설정합니다. 예를 들면 다음과 같습니다.

    # semanage fcontext -a -t mail_spool_t "<path>(/.*)?"
    # restorecon -Rv <path>
  3. vmail 사용자에게 /var/mail/ 에 대한 쓰기 권한을 부여합니다.

    # chown vmail:vmail /var/mail/
    # chmod 700 /var/mail/
  4. /etc/dovecot/conf.d/10-mail.conf 파일에서 mail_location 매개 변수의 주석을 해제하고 이 매개 변수를 copy 형식 및 위치로 설정합니다.

    mail_location = sdbox:/var/mail/%n/

    이 설정으로 다음을 수행합니다.

    • Dovecot는 high-performant dbox box format을 단일 모드에서 사용합니다. 이 모드에서 서비스는 maildir 형식과 유사하게 각 이메일을 별도의 파일에 저장합니다.
    • dovecot는 사용자 이름 경로의 %n 변수를 해결합니다. 이 작업은 각 사용자에게 해당 2.10에 대한 별도의 디렉터리가 있는지 확인하는 데 필요합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/VirtualUsers.txt
  • /usr/share/doc/dovecot/wiki/MailLocation.txt
  • /usr/share/doc/dovecot/wiki/MailboxFormat.dbox.txt
  • /usr/share/doc/dovecot/wiki/Variables.txt

1.3.4. MariaDB SQL 데이터베이스를 Dovecot 인증 백엔드로 사용

dovecot는 MariaDB 데이터베이스에서 계정과 암호를 읽고 해당 사용자를 사용하여 Manila 또는 POP3 서비스에 로그인할 때 사용자를 인증할 수 있습니다. 이 인증 방법의 장점은 다음과 같습니다.

  • 관리자는 데이터베이스에서 사용자를 중앙에서 관리할 수 있습니다.
  • 사용자는 서버에서 로컬로 액세스할 수 없습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • 가상 사용자 기능이 구성됩니다.
  • MariaDB 서버에 대한 연결은 TLS 암호화를 지원합니다.
  • dovecotDB 데이터베이스는 MariaDB에 있으며 users 테이블에는 적어도 usernamepassword 열이 포함됩니다.
  • 암호 열에는 Dovecot에서 지원하는 스키마로 암호화된 암호가 포함되어 있습니다.
  • 암호는 동일한 스키마를 사용하거나 {pw-storage-scheme} 접두사가 있습니다.
  • dovecot MariaDB 사용자는 dovecotDB 데이터베이스의 users 테이블에 대한 읽기 권한이 있습니다.
  • MariaDB 서버의 TLS 인증서를 발행한 인증 기관(CA) 인증서는 /etc/pki/tls/certs/ca.crt 파일의 Dovecot 서버에 저장됩니다.
  • MariaDB 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 이 Dovecot 서버는 확장 마스터 시크릿(ECDSA) 확장을 지원하거나 TLS 1.3을 사용합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.

절차

  1. dovecot-mysql 패키지를 설치합니다.

    # dnf install dovecot-mysql
  2. /etc/dovecot/conf.d/10-auth.conf 파일에서 인증 백엔드를 구성합니다.

    1. 주석 처리에 auth-*.conf.ext 인증 백엔드 구성 파일에 대한 설명이 포함되어 있습니다. 예를 들면 다음과 같습니다.

      #!include auth-system.conf.ext
    2. 다음 줄의 주석을 해제하여 SQL 인증을 활성화합니다.

      !include auth-sql.conf.ext
  3. /etc/dovecot/conf.d/auth-sql.conf.ext 파일을 편집하고 다음과 같이 override_fields 매개변수를 userdb 섹션에 추가합니다.

    userdb {
      driver = sql
      args = /etc/dovecot/dovecot-sql.conf.ext
      override_fields = uid=vmail gid=vmail home=/var/mail/%n/
    }

    고정 값으로 인해 Dovecot는 SQL Server에서 이러한 설정을 쿼리하지 않습니다.

  4. 다음 설정으로 /etc/dovecot/dovecot-sql.conf.ext 파일을 만듭니다.

    driver = mysql
    connect = host=mariadb_srv.example.com dbname=dovecotDB user=dovecot password=dovecotPW ssl_ca=/etc/pki/tls/certs/ca.crt
    default_pass_scheme = SHA512-CRYPT
    user_query = SELECT username FROM users WHERE username='%u';
    password_query = SELECT username AS user, password FROM users WHERE username='%u';
    iterate_query = SELECT username FROM users;

    데이터베이스 서버에 TLS 암호화를 사용하려면 ssl_ca 옵션을 MariaDB 서버 인증서를 발행한 CA 인증서의 경로로 설정합니다. 작업 인증서 검증을 위해 MariaDB 서버의 호스트 이름이 TLS 인증서에 사용된 호스트 이름과 일치해야 합니다.

    데이터베이스의 암호 값에 {pw-storage-scheme} 접두사가 포함된 경우 default_pass_scheme 설정을 생략할 수 있습니다.

    파일의 쿼리는 다음과 같이 설정해야 합니다.

    • user_query 매개변수의 경우 쿼리에서 Dovecot 사용자의 사용자 이름을 반환해야 합니다. 또한 쿼리는 하나의 결과만 반환해야 합니다.
    • password_query 매개변수의 경우 쿼리에서 사용자 이름과 암호를 반환해야 하며 Dovecot는 사용자암호 변수에 이러한 값을 사용해야 합니다. 따라서 데이터베이스에서 다른 열 이름을 사용하는 경우 AS SQL 명령을 사용하여 결과의 열의 이름을 바꿉니다.
    • iterate_query 매개변수의 경우 쿼리에서 모든 사용자 목록을 반환해야 합니다.
  5. /etc/dovecot/dovecot-sql.conf.ext 파일에 대한 보안 권한을 설정합니다.

    # chown root:root /etc/dovecot/dovecot-sql.conf.ext
    # chmod 600 /etc/dovecot/dovecot-sql.conf.ext

추가 리소스

  • /usr/share/doc/dovecot/example-config/dovecot-sql.conf.ext
  • /usr/share/doc/dovecot/wiki/Authentication.PasswordSchemes.txt

1.3.5. Dovecot 구성 완료

Dovecot를 설치 및 구성한 후 firewalld 서비스에서 필요한 포트를 열고 서비스를 활성화 및 시작합니다. 그런 다음 서버를 테스트할 수 있습니다.

사전 요구 사항

  • Dovecot에서 다음 내용이 구성되어 있습니다.

    • TLS 암호화
    • 인증 백엔드
  • 클라이언트는 CA(인증 기관) 인증서를 신뢰합니다.

절차

  1. 사용자에게 CloudEvent 또는 POP3 서비스만 제공하려면 /etc/dovecot/dovecot.conf 파일에서 protocols 매개변수의 주석을 제거하고 필요한 프로토콜로 설정합니다. 예를 들어, POP3이 필요하지 않은 경우 다음을 설정합니다.

    protocols = imap lmtp

    기본적으로 imap,pop3, lmtp 프로토콜이 활성화됩니다.

  2. 로컬 방화벽에서 포트를 엽니다. 예를 들어, CloudEventS,Forwarded, POP3S 및 POP3 프로토콜의 포트를 여는 경우 다음을 입력합니다.

    # firewall-cmd --permanent --add-service=imaps --add-service=imap --add-service=pop3s --add-service=pop3
    # firewall-cmd --reload
  3. dovecot 서비스를 활성화하고 시작합니다.

    # systemctl enable --now dovecot

검증

  1. Mozilla Thunderbird와 같은 메일 클라이언트를 사용하여 Dovecot에 연결하고 이메일을 읽습니다. 메일 클라이언트 설정은 사용하려는 프로토콜에 따라 다릅니다.

    표 1.3. Dovecot 서버에 대한 연결 설정

    프로토콜포트연결 보안인증 방법

    IMAP

    143

    STARTTLS

    PLAIN[a]

    IMAPS

    993

    SSL/TLS

    PLAIN[a]

    POP3

    110

    STARTTLS

    PLAIN[a]

    POP3S

    995

    SSL/TLS

    PLAIN[a]

    [a] 클라이언트는 TLS 연결을 통해 암호화된 데이터를 전송합니다. 따라서 인증 정보가 공개되지 않습니다.

    기본적으로 Dovecot는 TLS가 없는 연결에서 일반 텍스트 인증을 허용하지 않으므로 이 테이블에는 암호화되지 않은 연결의 설정이 나열되지 않습니다.

  2. 기본값이 아닌 값을 사용하여 구성 설정을 표시합니다.

    # doveconf -n

추가 리소스

  • firewall-cmd(1) 매뉴얼 페이지

1.4. 두 개의 Dovecot 서버 간 복제 구성

양방향 복제를 사용하면 Dovecot 서버를 고가용성으로 만들 수 있으며, Bookinfo 및 POP3 클라이언트가 두 서버의 kdump에 액세스할 수 있습니다. Dovecot는 각box의 인덱스 로그의 변경 사항을 추적하고 안전한 방식으로 충돌을 해결합니다.

두 복제 파트너 모두에서 이 절차를 수행합니다.

참고

복제는 서버 쌍 간에만 작동합니다. 결과적으로 대규모 클러스터에서는 여러 개의 독립적인 백엔드 쌍이 필요합니다.

사전 요구 사항

  • 두 서버 모두 동일한 인증 백엔드를 사용합니다. LDAP 또는 SQL을 사용하여 계정을 중앙에서 유지하는 것이 좋습니다.
  • Dovecot 사용자 데이터베이스 구성은 사용자 목록을 지원합니다. doveadm user '*' 명령을 사용하여 이를 확인합니다.
  • dovecot는 사용자 ID(UID) 대신 vmail 사용자로 파일 시스템의 kdump에 액세스합니다.

절차

  1. /etc/dovecot/conf.d/10-replication.conf 파일을 만들고 여기에 다음 단계를 수행합니다.

    1. notifyreplication 플러그인을 활성화합니다.

      mail_plugins = $mail_plugins notify replication
    2. 서비스 복제 기 섹션을 추가합니다.

      service replicator {
        process_min_avail = 1
      
        unix_listener replicator-doveadm {
          mode = 0600
          user = vmail
        }
      }

      이러한 설정으로 Dovecot는 dovecot 서비스가 시작될 때 하나 이상의 replicator 프로세스를 시작합니다. 또한 이 섹션에서는 replicator-doveadm 소켓의 설정을 정의합니다.

    3. 서비스 집계 기 섹션을 추가하여 replication-notify-fifo 파이프 및 replication-notify 소켓을 구성합니다.

      service aggregator {
        fifo_listener replication-notify-fifo {
          user = vmail
        }
        unix_listener replication-notify {
          user = vmail
        }
      }
    4. 서비스 doveadm 섹션을 추가하여 복제 서비스의 포트를 정의합니다.

      service doveadm {
        inet_listener {
          port = 12345
        }
      }
    5. doveadm 복제 서비스의 암호를 설정합니다.

      doveadm_password = replication_password

      두 서버에서 암호는 동일해야 합니다.

    6. 복제 파트너를 구성합니다.

      plugin {
        mail_replica = tcp:server2.example.com:12345
      }
    7. 선택 사항: 최대 병렬 dsync 프로세스 수를 정의합니다.

      replication_max_conns = 20

      replication_max_conns 의 기본값은 10 입니다.

  2. /etc/dovecot/conf.d/10-replication.conf 파일에 보안 권한을 설정합니다.

    # chown root:root /etc/dovecot/conf.d/10-replication.conf
    # chmod 600 /etc/dovecot/conf.d/10-replication.conf
  3. nis_enabled SELinux 부울을 활성화하여 Dove adm 복제 포트를 열 수 있습니다.

    setsebool -P nis_enabled on
  4. 복제 파트너만 복제 포트에 액세스할 수 있도록 firewalld 규칙을 구성합니다. 예를 들면 다음과 같습니다.

    # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.0.2.1/32" port protocol="tcp" port="12345" accept"
    # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv6" source address="2001:db8:2::1/128" port protocol="tcp" port="12345" accept"
    # firewall-cmd --reload

    IPv6 주소에 대한 서브넷 마스크 / 32 및 IPv6 주소의 서브넷 마스크는 지정된 주소에 대한 액세스를 제한합니다.

  5. 다른 복제 파트너에서도 이 절차를 수행하십시오.
  6. 다시 로드 Dovecot:

    # systemctl reload dovecot

검증

  1. 한 서버의 Webhook에서 작업을 수행한 다음 Dovecot가 변경 사항을 다른 서버에 복제했는지 확인합니다.
  2. 복제자 상태를 표시합니다.

    # doveadm replicator status
    Queued 'sync' requests        0
    Queued 'high' requests        0
    Queued 'low' requests         0
    Queued 'failed' requests      0
    Queued 'full resync' requests 30
    Waiting 'failed' requests     0
    Total number of known users   75
  3. 특정 사용자의 복제본 상태를 표시합니다.

    # doveadm replicator status example_user
    username        priority  fast sync  full sync  success sync  failed
    example_user    none      02:05:28   04:19:07   02:05:28      -

추가 리소스

  • dsync(1) man page
  • /usr/share/doc/dovecot/wiki/Replication.txt

1.5. 사용자 구독이 CloudEventVerifyboxes에 자동으로 가입

일반적으로, CloudEvent 서버 관리자는 Dovecot가 SentTrash 와 같은 특정 Webhook를 자동으로 생성하고 사용자를 구독하려고 합니다. 구성 파일에서 이 값을 설정할 수 있습니다.

또한, 특수한 속성을 정의할 수 있습니다. gRPC 클라이언트는 종종 이메일 전송과 같은 특별한 목적으로 kdump를 정의하는 것을 지원합니다. 사용자가 올바른 Webhook를 수동으로 선택하고 설정해야 하는 것을 방지하기 위해 CloudEvent 서버는 Bookinfo LIST 명령에서 특수 사용 특성을 보낼 수 있습니다. 그러면 클라이언트가 이 특성을 사용하여 전송된 이메일에 대한 kdump를 식별하고 설정할 수 있습니다.

사전 요구 사항

  • dovecot가 구성되어 있습니다.

절차

  1. /etc/dovecot/conf.d/15-mailboxes.conf 파일에서 받은 편지함 네임스페이스 섹션을 업데이트합니다.

    1. 사용자가 사용할 수 있어야 하는 각각의 특수한 HSM에 auto = subscribe 설정을 추가합니다. 예를 들면 다음과 같습니다.

      namespace inbox {
        ...
        mailbox Drafts {
          special_use = \Drafts
          auto = subscribe
        }
      
        mailbox Junk {
          special_use = \Junk
          auto = subscribe
        }
      
        mailbox Trash {
          special_use = \Trash
          auto = subscribe
        }
      
        mailbox Sent {
          special_use = \Sent
          auto = subscribe
        }
        ...
      }

      메일 클라이언트가 더 특수한 사용의 Webhook를 지원하는 경우 유사한 항목을 추가할 수 있습니다. special_use 매개변수는 Dovecot가 클라이언트에게 특수 사용 속성에 전송하는 값을 정의합니다.

    2. 선택 사항: 특수한 용도가 없는 다른 Webhook를 정의하려면 사용자의 받은 편지함에 있는 kdump 섹션을 추가합니다.

      namespace inbox {
        ...
        mailbox "Important Emails" {
          auto = <value>
        }
        ...
      }

      auto 매개변수를 다음 값 중 하나로 설정할 수 있습니다.

      • 구독 (Subscribe) : 속성을 자동으로 생성하고 사용자를 구독합니다.
      • 만들기: 자동으로 사용자를 가입하지 않고 속성을 만듭니다.
      • No (default): Dovecot neither creates thebox or does it subscribe the user to it.
  2. 다시 로드 Dovecot:

    # systemctl reload dovecot

검증

  • CloudEvent 클라이언트를 사용하고 사용자 name에 액세스할 수 있습니다.

    auto = subscribe 설정이 있는 boxes가 자동으로 표시됩니다. 클라이언트가 특수한 사용 위치 및 정의된 목적을 지원하는 경우 클라이언트는 이를 자동으로 사용합니다.

추가 리소스

1.6. LMTP 소켓 및 LMTPS 리스너 구성

10.0.0.1과 같은 SMTP 서버는 Dovecot에 이메일을 전송하도록 LSTP(Local mail Transfer Protocol)를 사용합니다. SMTP 서버가 실행되는 경우:

  • Dovecot와 동일한 호스트에서 LMTP 소켓을 사용하십시오.
  • 다른 호스트에서 LMTP 서비스를 사용하십시오.

    기본적으로 LMTP 프로토콜은 암호화되지 않습니다. 그러나 TLS 암호화를 구성한 경우 Dovecot는 LMTP 서비스에 동일한 설정을 자동으로 사용합니다. 그런 다음 SMTP 서버는 LMTPS 프로토콜 또는 LMTP를 통해 10.0.0.1 TLS 명령을 사용하여 연결할 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.
  • LMTP 서비스를 구성하려면 Dovecot에서 TLS 암호화가 구성됩니다.

절차

  1. LMTP 프로토콜이 활성화되어 있는지 확인합니다.

    # doveconf -a | egrep "^protocols"
    protocols = imap pop3 lmtp

    출력에 lmtp 가 포함된 경우 프로토콜이 활성화됩니다.

  2. lmtp 프로토콜이 비활성화된 경우 /etc/dovecot/dovecot.conf 파일을 편집하고 protocol 매개변수의 값에 lmtp 를 추가합니다.

    protocols = ... lmtp
  3. LMTP 소켓 또는 서비스가 필요한지 여부에 따라 /etc/dovecot/conf.d/10-master.conf 파일의 lmtp 섹션에서 다음 사항을 변경합니다.

    • LMTP 소켓: 기본적으로 Dovecot는 /var/run/dovecot/lmtp 소켓을 자동으로 생성합니다.

      선택 사항: 소유권 및 권한을 사용자 지정합니다.

      service lmtp {
        ...
        unix_listener lmtp {
          mode = 0600
          user = postfix
          group = postfix
        }
        ...
      }
    • LMTP 서비스: inet_listener 하위 섹션을 추가합니다.

      service lmtp {
        ...
        inet_listener lmtp {
          port = 24
        }
        ...
      }
  4. SMTP 서버만 LMTP 포트에 액세스할 수 있도록 firewalld 규칙을 구성합니다. 예를 들면 다음과 같습니다.

    # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.0.2.1/32" port protocol="tcp" port="24" accept"
    # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv6" source address="2001:db8:2::1/128" port protocol="tcp" port="24" accept"
    # firewall-cmd --reload

    IPv6 주소에 대한 서브넷 마스크 / 32 및 IPv6 주소의 서브넷 마스크는 지정된 주소에 대한 액세스를 제한합니다.

  5. 다시 로드 Dovecot:

    # systemctl reload dovecot

검증

  1. LMTP 소켓을 구성한 경우 Dovecot가 소켓을 생성하고 권한이 올바른지 확인합니다.

    # ls -l /var/run/dovecot/lmtp
    srw-------. 1 postfix postfix 0 Nov 22 17:17 /var/run/dovecot/lmtp
  2. LMTP 소켓 또는 서비스를 사용하여 Dovecot에 이메일을 제출하도록 SMTP 서버를 구성합니다.

    LMTP 서비스를 사용하는 경우 SMTP 서버가 LMTPS 프로토콜을 사용하는지 확인하거나 encrypted connection 을 사용하도록 CloudEventTLS 명령을 보냅니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/LMTP.txt

1.7. Dovecot에서 CloudEvent 또는 POP3 서비스 비활성화

기본적으로 Dovecot는 CloudEvent 및 POP3 서비스를 제공합니다. 그 중 하나만 필요한 경우 다른 하나를 비활성화하여 공격을 위해 표면을 줄일 수 있습니다.

사전 요구 사항

  • dovecot가 설치되어 있어야 합니다.

절차

  1. /etc/dovecot/dovecot.conf 파일에서 protocols 매개변수의 주석을 제거하고 필요한 프로토콜을 사용하도록 설정합니다. 예를 들어, POP3이 필요하지 않은 경우 다음을 설정합니다.

    protocols = imap lmtp

    기본적으로 imap,pop3, lmtp 프로토콜이 활성화됩니다.

  2. 다시 로드 Dovecot:

    # systemctl reload dovecot
  3. 로컬 방화벽에 더 이상 필요하지 않은 포트를 닫습니다. 예를 들어, POP3S 및 POP3 프로토콜의 포트를 종료하려면 다음을 입력합니다.

    # firewall-cmd --remove-service=pop3s --remove-service=pop3
    # firewall-cmd --reload

검증

  • dovecot 프로세스에서 열린 LISTEN 모드에서 모든 포트를 표시합니다.

    # ss -tulp | grep dovecot
    tcp  LISTEN 0  100  0.0.0.0:993  0.0.0.0:*  users:(("dovecot",pid=1405,fd=44))
    tcp  LISTEN 0  100  0.0.0.0:143  0.0.0.0:*  users:(("dovecot",pid=1405,fd=42))
    tcp  LISTEN 0  100     [::]:993     [::]:*  users:(("dovecot",pid=1405,fd=45))
    tcp  LISTEN 0  100     [::]:143     [::]:*  users:(("dovecot",pid=1405,fd=43))

    이 예에서 Dovecot는 TCP 포트 993 (IMAPS) 및 143 (IMAP)에서만 수신 대기합니다.

    소켓을 사용하는 대신 포트에서 수신 대기하도록 서비스를 구성하는 경우 Dovecot는 LMTP 프로토콜의 포트만 엽니다.

추가 리소스

  • firewall-cmd(1) 매뉴얼 페이지

1.8. Dove servers에서 Sieve를 사용하여 서버 측 이메일 필터링 활성화

관리 프로토콜을 사용하여 Sieve 스크립트를 서버에 업로드할 수 있습니다. Sieve 스크립트는 서버가 수신되는 이메일에서 검증하고 수행해야 하는 규칙과 작업을 정의합니다. 예를 들어, 사용자는 Sieve를 사용하여 특정 발신자의 이메일을 전달할 수 있으며 관리자는 글로벌 필터를 생성하여 스팸 필터에 의해 플래그가 지정된 이메일을 별도의 CloudEvent 폴더로 이동할 수 있습니다.

ManageSieve 플러그인은 Sieve 스크립트 및 ManageSieve 프로토콜에 대한 지원을 Dove server에 추가합니다.

주의

TLS 연결을 통해 ManageSieve 프로토콜 사용을 지원하는 클라이언트만 사용합니다. 이 프로토콜의 TLS를 비활성화하면 클라이언트가 네트워크를 통해 일반 텍스트로 자격 증명을 보냅니다.

사전 요구 사항

  • Dovecot가 구성되었으며, usevecot를 제공합니다.
  • TLS 암호화는 Dovecot에서 구성됩니다.
  • 메일 클라이언트는 TLS 연결을 통해 ManageSieve 프로토콜을 지원합니다.

절차

  1. dovecot-pigeon absent 패키지를 설치합니다.

    # dnf install dovecot-pigeonhole
  2. /etc/dovecot/conf.d/20-managesieve.conf 에서 다음 줄의 주석을 제거하여 sieve 프로토콜을 활성화합니다.

    protocols = $protocols sieve

    이 설정은 이미 활성화된 다른 프로토콜 외에 Sieve를 활성화합니다.

  3. firewalld 에서 ManageSieve 포트를 엽니다.

    # firewall-cmd --permanent --add-service=managesieve
    # firewall-cmd --reload
  4. 다시 로드 Dovecot:

    # systemctl reload dovecot

검증

  1. 클라이언트를 사용하고 Sieve 스크립트를 업로드합니다. 다음 연결 설정을 사용합니다.

    • 포트: 4190
    • 연결 보안: SSL/TLS
    • 인증 방법: PLAIN
  2. Sieve 스크립트가 업로드된 사용자에게 이메일을 보냅니다. 이메일이 스크립트의 규칙과 일치하는 경우 서버가 정의된 작업을 수행하는지 확인합니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/Pigeonhole.Sieve.Plugins.IMAPSieve.txt
  • /usr/share/doc/dovecot/wiki/Pigeonhole.Sieve.Troubleshooting.txt
  • firewall-cmd(1) 매뉴얼 페이지

1.9. Dovecot에서 구성 파일을 처리하는 방법

dovecot 패키지는 기본 설정 파일 /etc/dovecot/dovecot.conf/etc/dovecot/conf.d/ 디렉터리에 여러 구성 파일을 제공합니다. Dovecot는 파일을 결합하여 서비스를 시작할 때 구성을 빌드합니다.

여러 구성 파일의 주요 장점은 그룹화 설정을 수행하고 가독성을 높이는 것입니다. 단일 구성 파일을 선호하는 경우 /etc/dovecot/dovecot.conf 의 모든 설정을 유지 관리하고 해당 파일에서 include _try 문을 모두 제거할 수 있습니다.

추가 리소스

  • /usr/share/doc/dovecot/wiki/ConfigFile.txt
  • /usr/share/doc/dovecot/wiki/Variables.txt

2장. SriovNetwork SMTP 서버 배포 및 구성

시스템 관리자는 messages와 같은 메일 전송 에이전트(MTA)를 사용하여 SMTP 프로토콜을 사용하여 호스트 간에 이메일 메시지를 전송할 수 있습니다. nodeSelector는 메일 라우팅 및 전송을 위한 서버 측 애플리케이션입니다. SriovNetwork를 사용하여 로컬 메일 서버를 설정하거나 null-client 메일 릴레이를 생성하거나, ReplicaSet 서버를 여러 도메인의 대상으로 사용하거나, 조회를 위해 파일 대신 LDAP 디렉터리를 선택할 수 있습니다.

dhcp의 주요 기능:

  • 일반적인 이메일 관련 위협으로부터 보호하는 보안 기능
  • 가상 도메인 및 별칭 지원을 포함한 사용자 정의 옵션

2.1. 주요 Geneve 구성 파일 개요

postfix 패키지는 /etc/ Cryostat/ 디렉터리에 여러 구성 파일을 제공합니다.

이메일 인프라를 구성하려면 다음 구성 파일을 사용합니다.

  • main.cf - nodeSelector의 글로벌 구성이 포함되어 있습니다.
  • master.cf - mail delivery를 수행하기 위해 다양한 프로세스와 Geneve 상호 작용을 지정합니다.
  • access - 액세스 규칙(예: Cryostat에 연결할 수 있는 호스트)을 지정합니다.
  • 전송 - 이메일 주소를 매핑하여 호스트를 릴레이합니다.
  • 별칭 - 사용자 ID 별칭을 설명하는 메일 프로토콜에 필요한 구성 가능한 목록을 포함합니다. 이 파일은 /etc/ 디렉토리에서 찾을 수 있습니다.

2.2. SriovNetwork SMTP 서버 설치 및 구성

email 메시지를 수신, 저장 및 전달하도록 SQLite SMTP 서버를 구성할 수 있습니다. 시스템 설치 중에 메일 서버 패키지를 선택하지 않으면 기본적으로 Geneve를 사용할 수 없습니다. 다음 단계를 수행하여 Cryostat를 설치합니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.
  • 시스템을 등록 합니다.
  • 전송 비활성화 및 제거:

    # dnf remove sendmail

절차

  1. OperatorHub를 설치합니다.

    # dnf install postfix
  2. Cryostat를 구성하려면 /etc/ Cryostat/main.cf 파일을 편집하고 다음과 같이 변경합니다.

    1. 기본적으로 NetworkAttach는 루프백 인터페이스에서만 이메일을 받습니다. 특정 인터페이스에서 수신 대기하도록 Geneve를 구성하려면 inet_interfaces 매개변수를 다음 인터페이스의 IP 주소로 업데이트합니다.

      inet_interfaces = 127.0.0.1/32, [::1]/128, 192.0.2.1, [2001:db8:1::1]

      모든 인터페이스에서 수신 대기하도록 nodeSelector를 구성하려면 다음을 설정합니다.

      inet_interfaces = all
    2. SriovNetwork가 gethostname() 함수에서 반환하는 FQDN(정규화된 도메인 이름)과 다른 호스트 이름을 사용하려면 myhostname 매개변수를 추가합니다.

      myhostname = <smtp.example.com>

      예를 들어, content 는 이 호스트 이름을 처리하는 이메일의 헤더에 추가합니다.

    3. 도메인 이름이 myhostname 매개변수의 항목과 다른 경우 mydomain 매개변수를 추가합니다.

      mydomain = <example.com>
    4. myorigin 매개변수를 추가하고 mydomain: 값으로 설정합니다.

      myorigin = $mydomain

      이 설정을 통해 Geneve는 호스트 이름 대신 로컬에 게시된 메일의 원본으로 도메인 이름을 사용합니다.

    5. mynetworks 매개변수를 추가하고 이메일을 보낼 수 있는 신뢰할 수 있는 네트워크의 IP 범위를 정의합니다.

      mynetworks = 127.0.0.1/32, [::1]/128, 192.0.2.1/24, [2001:db8:1::1]/64

      인터넷과 같은 신뢰할 수 없는 네트워크에서 클라이언트가 이 서버를 통해 이메일을 보낼 수 있어야 하는 경우 이후 단계에서 릴레이 제한 사항을 구성해야 합니다.

  3. main.cf 파일의 dhcp 구성이 올바른지 확인합니다.

    $ postfix check
  4. postfix 서비스가 부팅 시 시작되고 시작되도록 활성화합니다.

    # systemctl enable --now postfix
  5. 방화벽을 통해 smtp 트래픽을 허용하고 방화벽 규칙을 다시 로드합니다.

    # firewall-cmd --permanent --add-service smtp
    
    # firewall-cmd --reload

검증

  1. postfix 서비스가 실행 중인지 확인합니다.

    # systemctl status postfix
    • 선택 사항: 출력이 중지되거나 대기 중이거나 서비스가 실행 중이 아닌 경우 postfix 서비스를 다시 시작합니다.

      # systemctl restart postfix
    • 선택 사항: /etc/ Cryostat/ 디렉터리의 구성 파일의 옵션을 변경한 후 postfix 서비스를 다시 로드하여 해당 변경 사항을 적용합니다.

      # systemctl reload postfix
  2. 시스템의 로컬 사용자 간 이메일 통신을 확인합니다.

    # echo "This is a test message" | mail -s <SUBJECT> <user@mydomain.com>
  3. 클라이언트(server1)에서 메일 서버(server2)로 도메인 외부에서 이메일 주소로 이메일을 전송하여 메일 서버가 열려 있는 릴레이가 아닌지 확인합니다.

    1. 다음과 같이 server1/etc/ Cryostat/main.cf 파일을 편집합니다.

      relayhost = <ip_address_of_server2>
    2. 다음과 같이 server2/etc/ Cryostat/main.cf 파일을 편집합니다.

      mynetworks = <ip_address_of_server2>
    3. server1 에서 다음 이메일을 보냅니다.

      # echo "This is an open relay test message" | mail -s <SUBJECT> <user@example.com>
    4. /var/log/maillog 파일을 확인합니다.

      554 Relay access denied - the server is not going to relay.
      250 OK or similar - the server is going to relay.

문제 해결

  • 오류가 있는 경우 /var/log/maillog 파일을 확인합니다.

추가 리소스

2.3. Cryostat 서버의 TLS 설정 사용자 정의

이메일 트래픽을 암호화하고 보안을 강화하기 위해 자체 서명된 인증서 대신 CA(인증 기관)의 인증서를 사용하고 TLS(Transport Layer Security) 보안 설정을 사용자 지정하도록 tls를 구성할 수 있습니다. RHEL 9에서 TLS 암호화 프로토콜은 기본적으로 gp 서버에서 활성화됩니다. 기본 dhcp TLS 구성에는 인바운드 SMTP에 대한 자체 서명된 인증서와 아웃바운드 SMTP의 opportunistic TLS가 포함되어 있습니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.
  • postfix 패키지가 서버에 설치되어 있어야 합니다.
  • 신뢰할 수 있는 CA(인증 기관) 및 개인 키가 서명한 인증서가 있습니다.
  • 다음 파일을#187 서버에 복사했습니다.

    • 서버 인증서: /etc/pki/tls/certs/ Cryostat.pem
    • 개인 키: /etc/pki/tls/private/ Cryostat.key
  • 서버가 RHEL 9.2 이상을 실행하고 FIPS 모드가 활성화된 경우 클라이언트는 확장 마스터 시크릿(Extended Master Secret) 확장을 지원하거나 TLS 1.3을 사용해야 합니다. TLS 1.2 연결이 없는 경우 실패합니다. 자세한 내용은 TLS 확장 "Extended Master Secret" enforced Knowledgebase 문서를 참조하십시오.

절차

  1. /etc/ Cryostat/main.cf 파일에 다음 행을 추가하여 Cryostat가 실행되는 서버의 인증서 및 개인 키 파일의 경로를 설정합니다.

    smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
    smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
  2. /etc/ Cryostat/main.cf 파일을 편집하여 인증된 사용자에게만 들어오는 SMTP 연결을 제한합니다.

    smtpd_tls_auth_only = yes
  3. postfix 서비스를 다시 로드하여 변경 사항을 적용합니다.

    # systemctl reload postfix

검증

  • TLS 암호화를 사용하고 이메일을 보내도록 클라이언트를 구성합니다.

    참고

    Cryostat 클라이언트 TLS 활동에 대한 추가 정보를 얻으려면 /etc/ Cryostat/main.cf에서 다음 행을 변경하여 로그 수준을 0 에서 1 로 늘립니다.

    smtp_tls_loglevel = 1

2.4. 모든 이메일을 메일 릴레이로 전달하도록 nodeSelector 구성

모든 이메일을 메일 릴레이로 전달하려면 Cryostat 서버를 null 클라이언트로 구성할 수 있습니다. 이 구성에서 Geneve는 다른 메일 서버로만 메일만 전달하며 이메일을 수신할 수 없습니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.
  • postfix 패키지가 서버에 설치되어 있어야 합니다.
  • 이메일을 전달하려는 릴레이 호스트의 IP 주소 또는 호스트 이름이 있습니다.

절차

  1. Cryostat가 로컬 이메일 전송을 수락하지 않고 null 클라이언트로 만들지 않으려면 /etc/ Cryostat/main.cf 파일을 편집하고 다음과 같이 변경합니다.

    1. mydestination 매개변수를 빈 값과 동일하게 설정하여 모든 이메일을 전달하도록 dhcp를 구성합니다.

      mydestination =

      이 구성에서 content 서버는 이메일의 대상이 아니며 null 클라이언트 역할을 합니다.

    2. null 클라이언트에서 이메일을 수신하는 메일 릴레이 서버를 지정합니다.

      relayhost = <[ip_address_or_hostname]>

      릴레이 호스트는 메일 전송을 담당합니다. 대괄호로 <ip_address_or_hostname& gt;을 묶습니다.

    3. 이메일이 전달할 루프백 인터페이스에서만 수신 대기하도록 CloudEvent 메일 서버를 구성합니다.

      inet_interfaces = loopback-only
    4. 모든 발신 이메일의 보낸 사람 도메인을 릴레이 메일 서버의 회사 도메인으로 다시 작성하려면 다음을 설정합니다.

      myorigin = <relay.example.com>
    5. 로컬 메일 전송을 비활성화하려면 구성 파일 끝에 다음 지시문을 추가합니다.

      local_transport = error: local delivery disabled
    6. 왼쪽이 127.0.0.0/8 IPv4 네트워크 및 [::1]/128 IPv6 네트워크에서 메일 릴레이 서버로 이메일을 전달하도록 mynetworks 매개변수를 추가합니다.

      mynetworks = 127.0.0.0/8, [::1]/128
  2. main.cf 파일의 dhcp 구성이 올바른지 확인합니다.

    $ postfix check
  3. postfix 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart postfix

검증

  • 이메일 통신이 메일 릴레이로 전달되었는지 확인합니다.

    # echo "This is a test message" | mail -s <SUBJECT> <user@example.com>

문제 해결

  • 오류가 있는 경우 /var/log/maillog 파일을 확인합니다.

추가 리소스

  • /etc/ Cryostat/main.cf 구성 파일

2.5. SriovNetwork를 여러 도메인의 대상으로 구성

postfix는 여러 도메인에 대한 이메일을 수신할 수 있는 메일 서버로 구성할 수 있습니다. 이 구성에서 Geneve는 지정된 도메인 내의 주소로 전송된 이메일의 최종 대상 역할을 합니다. 다음을 구성할 수 있습니다.

  • 동일한 이메일 대상을 가리키는 여러 이메일 주소 설정
  • 여러 도메인에 대한 들어오는 이메일 라우팅을 동일한 Cryostat 서버로 라우팅

사전 요구 사항

  • 루트 액세스 권한이 있습니다.
  • KubeletConfig 서버를 구성했습니다.

절차

  1. /etc/ Cryostat/virtual virtual alias 파일에서 각 도메인의 이메일 주소를 지정합니다. 새 줄에 각 이메일 주소를 추가합니다.

    <info@example.com>  <user22@example.net>
    <sales@example.com>  <user11@example.org>

    이 예에서 samba는 user22@example.net로 전송된 모든 이메일을 user22@example.net로 리디렉션하고 sales@example.com에 전송된 이메일은 user11@example.org로 리디렉션합니다.

  2. 가상 별칭 맵의 해시 파일을 생성합니다.

    # postmap /etc/postfix/virtual

    이 명령은 /etc/ Cryostat/virtual.db 파일을 생성합니다. /etc/ Cryostat/virtual 파일을 업데이트한 후 항상 이 명령을 다시 실행해야 합니다.

  3. Cryostat /etc/ Cryostat/main.cf 구성 파일에서 virtual_alias_maps 매개변수를 추가하고 해시 파일을 가리킵니다.

    virtual_alias_maps = hash:/etc/postfix/virtual
  4. postfix 서비스를 다시 로드하여 변경 사항을 적용합니다.

    # systemctl reload postfix

검증

  • 가상 이메일 주소 중 하나로 이메일을 전송하여 구성을 테스트합니다.

문제 해결

  • 오류가 있는 경우 /var/log/maillog 파일을 확인합니다.

2.6. LDAP 디렉터리를 조회 테이블로 사용

LDAP(Lightweight Directory Access Protocol) 서버를 사용하여 계정, 도메인 또는 별칭을 저장하는 경우 LDAP 서버를 조회 테이블로 사용하도록 HPA를 구성할 수 있습니다. 조회에 파일 대신 LDAP를 사용하면 중앙 데이터베이스를 사용할 수 있습니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.
  • postfix 패키지가 서버에 설치되어 있어야 합니다.
  • 필요한 스키마 및 사용자 인증 정보가 있는 LDAP 서버가 있습니다.
  • GPO를 실행하는 서버에 postfix-ldap 플러그인이 설치되어 있어야 합니다.

절차

  1. 다음 내용으로 /etc/ Cryostat/ldap-aliases.cf 파일을 생성하여 LDAP 조회 매개변수를 구성합니다.

    1. LDAP 서버의 호스트 이름을 지정합니다.

      server_host = <ldap.example.com>
    2. LDAP 검색의 기본 도메인 이름을 지정합니다.

      search_base = dc=<example>,dc=<com>
    3. 선택 사항: 요구 사항에 따라 LDAP 검색 필터 및 속성을 사용자 지정합니다. 디렉터리를 검색하는 필터의 기본값은 query_filter = mailacceptinggeneralid=%s 입니다.
  2. 다음 콘텐츠를 추가하여 /etc/ Cryostat/main.cf 구성 파일에서 LDAP 소스를 조회 테이블로 활성화합니다.

    virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
  3. 구문 오류 또는 연결 문제를 확인하는 postmap 명령을 실행하여 LDAP 구성을 확인합니다.

    # postmap -q @<example.com> ldap:/etc/postfix/ldap-aliases.cf
  4. postfix 서비스를 다시 로드하여 변경 사항을 적용합니다.

    # systemctl reload postfix

검증

  • 테스트 이메일을 보내 LDAP 조회가 올바르게 작동하는지 확인합니다. /var/log/maillog 의 메일 로그에서 오류가 있는지 확인합니다.

추가 리소스

  • /usr/share/doc/ Cryostat/README_FILES/LDAP_README 파일
  • /usr/share/doc/ Cryostat/README_FILES/DATABASE_README 파일

2.7. 인증된 사용자를 위해 중계하도록 SriovNetwork를 발신 메일 서버로 구성

인증된 사용자의 메일에 대해 릴레이하도록 SriovNetwork를 구성할 수 있습니다. 이 시나리오에서는 사용자가 자신을 인증하고 SMTP 인증, TLS 암호화 및 보낸 사람 주소 제한이 있는 발신 메일 서버로 postfix를 구성하여 이메일 주소를 사용하여 SMTP 서버를 통해 이메일을 보낼 수 있습니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.
  • KubeletConfig 서버를 구성했습니다.

절차

  1. Cryostat를 발신 메일 서버로 구성하려면 /etc/ Cryostat/main.cf 파일을 편집하고 다음을 추가합니다.

    1. SMTP 인증을 활성화합니다.

      smtpd_sasl_auth_enable = yes
      broken_sasl_auth_clients = yes
    2. TLS 없이 액세스를 비활성화합니다.

      smtpd_tls_auth_only = yes
    3. 인증된 사용자만 메일 중계를 허용합니다.

      smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
    4. 선택 사항: 사용자가 자신의 이메일 주소를 발신자로만 사용하도록 제한합니다.

      smtpd_sender_restrictions = reject_sender_login_mismatch
  2. postfix 서비스를 다시 로드하여 변경 사항을 적용합니다.

    # systemctl reload postfix

검증

  • TLS 및 SASL을 지원하는 SMTP 클라이언트에서 인증합니다. 테스트 이메일을 보내 SMTP 인증이 올바르게 작동하는지 확인합니다.

2.8. 동일한 호스트에서 실행 중인 SriovNetwork에서 Dovecot에 이메일 전달

UNIX 소켓을 통해 LMTP를 사용하여 동일한 호스트에서 수신한 이메일을 Dovecot에 전달하도록 Geneve를 구성할 수 있습니다. 이 소켓을 사용하면 로컬 시스템의 Cryostat와 Dovecot 간에 직접 통신할 수 있습니다.

사전 요구 사항

절차

  1. /etc/ Cryostat/main.cf 파일에서 Dovecot에 메일 전달을 위해 LMTP 프로토콜과 UNIX 도메인 소켓을 사용하도록 rbd를 구성합니다.

    • 가상 Cryostat를 사용하려면 다음 콘텐츠를 추가합니다.

      virtual_transport = lmtp:unix:/var/run/dovecot/lmtp
    • 비가상 Cryostat를 사용하려면 다음 콘텐츠를 추가합니다.

      mailbox_transport = lmtp:unix:/var/run/dovecot/lmtp
  2. postfix 를 다시 로드하여 변경 사항을 적용합니다.

    # systemctl reload postfix

검증

  • 테스트 이메일을 보내 LMTP 소켓이 올바르게 작동하는지 확인합니다. /var/log/maillog 의 메일 로그에서 오류가 있는지 확인합니다.

2.9. 다른 호스트에서 실행 중인 tls에서 Dovecot에 이메일 전달

네트워크를 통해 Cryostat 메일 서버와 Dovecot 전달 에이전트 간에 보안 연결을 설정할 수 있습니다. 이렇게 하려면 메일 서버 간에 메일 전송에 네트워크 소켓을 사용하도록 LMTP 서비스를 구성합니다. 기본적으로 LMTP 프로토콜은 암호화되지 않습니다. 그러나 TLS 암호화를 구성한 경우 Dovecot는 LMTP 서비스에 동일한 설정을 자동으로 사용합니다. 그런 다음 SMTP 서버는 LMTP를 통해 STARTTLS 명령을 사용하여 연결할 수 있습니다.

사전 요구 사항

절차

  1. 다음 콘텐츠를 추가하여 /etc/ Cryostat/main.cf 파일에서 Dovecot에 메일 전달을 위해 LMTP 프로토콜과 INET 도메인 소켓을 사용하도록 rbd를 구성합니다.

    mailbox_transport = lmtp:inet:<dovecot_host>:<port>

    < dovecot_host >를 Dovecot 서버의 IP 주소 또는 호스트 이름으로 바꾸고 < port >를 LMTP 서비스의 포트 번호로 바꿉니다.

  2. postfix 서비스를 다시 로드하여 변경 사항을 적용합니다.

    # systemctl reload postfix

검증

  • 테스트 이메일을 원격 Dovecot 서버에서 호스팅하는 주소로 전송하고 Dovecot 로그를 확인하여 메일이 성공적으로 전달되었는지 확인합니다.

2.10. Geneve 서비스 보안

Cryostat는 SMTP(Simple Mail Transfer Protocol)를 사용하여 다른 MTA 간에 전자 메시지를 전달하고 클라이언트 또는 전달 에이전트에 전자 메시지를 전달하는 MTA(mail transfer agent)입니다. MTA는 서로 간에 트래픽을 암호화할 수 있지만 기본적으로 트래픽을 암호화하지 못할 수 있습니다. 또한 보안 값으로 설정을 변경하여 다양한 공격에 대한 위험을 완화할 수도 있습니다.

2.10.2. DoS 공격을 제한하기 위한 mTLS 구성 옵션

공격자는 트래픽으로 서버를 플러드하거나 충돌을 유발하는 정보를 전송하여 서비스 거부(DoS) 공격을 유발할 수 있습니다. /etc/ Cryostat/main.cf 파일에서 제한을 설정하여 이러한 공격의 위험을 줄이도록 시스템을 구성할 수 있습니다. 기존 지시문의 값을 변경하거나 < directive> = <value > 형식의 사용자 지정 값을 사용하여 새 지시문을 추가할 수 있습니다.

DoS 공격을 제한하려면 다음 지시문 목록을 사용합니다.

smtpd_client_connection_rate_limit
이 지시문은 클라이언트가 시간 단위당 이 서비스에 수행할 수 있는 최대 연결 시도 수를 제한합니다. 기본값은 0 입니다. 즉, 클라이언트에서 시간 단위당 networks에서 허용할 수 있는 만큼 많은 연결을 만들 수 있습니다. 기본적으로 지시문은 신뢰할 수 있는 네트워크의 클라이언트를 제외합니다.
anvil_rate_time_unit
이 지시문은 속도 제한을 계산하는 시간 단위입니다. 기본값은 60 초입니다.
smtpd_client_event_limit_exceptions
이 지시문은 connection 및 rate limit 명령에서 클라이언트를 제외합니다. 기본적으로 지시문은 신뢰할 수 있는 네트워크의 클라이언트를 제외합니다.
smtpd_client_message_rate_limit
이 지시문은 시간 단위당 요청하기 위해 클라이언트에서 최대 메시지 전달 수를 정의합니다(VPC가 이러한 메시지를 실제로 수락하는지의 여부 제외).
default_process_limit
이 지시문은 지정된 서비스를 제공하는 기본 최대 Cryostat 하위 프로세스 수를 정의합니다. master.cf 파일의 특정 서비스에 대해 이 규칙을 무시할 수 있습니다. 기본적으로 값은 100 입니다.
queue_minfree
이 지시문은 대기열 파일 시스템에서 메일 수신에 필요한 최소 여유 공간을 정의합니다. 이 지시문은 현재 Cryostat SMTP 서버에서 모든 메일이 수락되는지 여부를 결정하는 데 사용됩니다. 기본적으로, 사용 가능한 공간의 양이 message_size_limit 의 1.5배 미만일 때 CVO SMTP 서버는 MAIL FROM 명령을 거부합니다. 최소 사용 가능한 공간 제한을 지정하려면 message_size_limit 의 1.5배 이상의 queue_minfree 값을 지정합니다. 기본적으로 queue_minfree 값은 0 입니다.
header_size_limit
이 지시문은 메시지 헤더를 저장하기 위한 최대 메모리 양(바이트)을 정의합니다. 헤더가 크면 초과 헤더가 삭제됩니다. 기본적으로 값은 102400 바이트입니다.
message_size_limit
이 지시문은 바이트 단위 정보를 포함하여 메시지의 최대 크기를 정의합니다. 기본적으로 값은 10240000 바이트입니다.

2.10.3. SASL을 사용하도록 SriovNetwork 구성

Geneve는 SASL(Simple Authentication and Security Layer) 기반 SMTP 인증(AUTH)을 지원합니다. SMTP AUTH는 단순 메일 전송 프로토콜의 확장입니다. 현재 CVO SMTP 서버는 다음과 같은 방식으로 SASL 구현을 지원합니다.

Dovecot SASL
dhcp SMTP 서버는 UNIX 도메인 소켓 또는 TCP 소켓을 사용하여 Dovecot SASL 구현과 통신할 수 있습니다. Geneve 및 Dovecot 애플리케이션이 별도의 시스템에서 실행되는 경우 이 방법을 사용합니다.
Cyrus SASL
활성화된 경우 SMTP 클라이언트는 서버와 클라이언트에서 모두 지원 및 수락하는 인증 방법을 사용하여 SMTP 서버로 인증해야 합니다.

사전 요구 사항

  • dovecot 패키지가 시스템에 설치되어 있습니다.

절차

  1. Dovecot를 설정합니다.

    1. /etc/dovecot/conf.d/10-master.conf 파일에 다음 행을 포함합니다.

      service auth {
        unix_listener /var/spool/postfix/private/auth {
          mode = 0660
          user = postfix
          group = postfix
        }
      }

      이전 예제에서는 StorageClass와 Dovecot 간의 통신을 위해 UNIX-domain 소켓을 사용합니다. 이 예제에서는 /var/spool/ Cryostat/ 디렉터리에 있는 메일 큐와 postfix 사용자 및 그룹 아래에 실행되는 애플리케이션을 포함하는 기본 Cryostat SMTP 서버 설정도 가정합니다.

    2. 선택 사항: TCP를 통해ignore 인증 요청을 수신 대기하도록 Dovecot를 설정합니다.

      service auth {
        inet_listener {
            port = port-number
        }
      }
    3. /etc/dovecot/conf.d/10-auth.conf 파일에서 auth_mechanisms 매개변수를 편집하여 이메일 클라이언트가 Dovecot로 인증하는 데 사용하는 방법을 지정합니다.

      auth_mechanisms = plain login

      auth_mechanisms 매개변수는 다른 일반 텍스트 및 비 일반 텍스트 인증 방법을 지원합니다.

  2. /etc/ Cryostat/main.cf 파일을 수정하여 Cryostat를 설정합니다.

    1. Cryostat SMTP 서버에서 SMTP 인증을 활성화합니다.

      smtpd_sasl_auth_enable = yes
    2. SMTP 인증에 Dovecot SASL 구현을 활성화합니다.

      smtpd_sasl_type = dovecot
    3. Cryostat 큐 디렉터리를 기준으로 인증 경로를 제공합니다. 상대 경로를 사용하면 Cryostat 서버가 chroot 에서 실행되는지 여부에 관계없이 구성이 작동하는지 확인합니다.

      smtpd_sasl_path = private/auth

      이 단계에서는 StorageClass와 Dovecot 간의 통신에 UNIX-domain 소켓을 사용합니다.

      TCP 소켓을 사용하여 통신에 사용하는 경우 다른 시스템에서 Dovecot를 찾으려면 다음과 유사한 구성 값을 사용합니다.

      smtpd_sasl_path = inet: ip-address : port-number

      이전 예에서 ip-address 를 Dovecot 시스템의 IP 주소로 바꾸고 port-number 를 Dovecot의 /etc/dovecot/conf.d/10-master.conf 파일에 지정된 포트 번호로 바꿉니다.

    4. CVO SMTP 서버가 클라이언트에서 사용할 수 있도록 하는 SASL 메커니즘을 지정합니다. 암호화 및 암호화되지 않은 세션에 대해 다양한 메커니즘을 지정할 수 있습니다.

      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous

      이전 지시문은 암호화되지 않은 세션 중에 익명 인증이 허용되지 않으며 암호화되지 않은 사용자 이름 또는 암호를 전송하는 메커니즘이 허용되지 않도록 지정합니다. TLS를 사용하는 암호화된 세션의 경우 비익명 인증 메커니즘만 허용됩니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.