Zimbra에서 IP 주소를 기준으로 발신 이메일 릴레이를 제한하는 방법

Zimbra MTA를 통해 인증되지 않은 발신 메일을 보낼 수 있는 시스템을 제한하려면 해당 서버의 zimbraMtaMyNetworks속성을 신뢰할 수 있는 IP 주소 또는 CIDR 네트워크의 짧은 허용 목록으로 설정하십시오. 목록에 루프백 IP 주소를 포함하고, 릴레이가 필요한 기존 신뢰 호스트는 유지하며, 더 이상 신뢰하지 않을 광범위한 범위는 제거하십시오. 그런 다음 Postfix를 다시 시작하고 승인된 소스와 승인되지 않은 소스 모두를 테스트하십시오.

이 설정은 SMTP 인증 없이 릴레이할 수 있는 신뢰할 수 있는 SMTP 클라이언트를 제어합니다. 인증된 Zimbra 사용자의 모든 발신 메시지를 차단하거나 다음 홉 메일 서버를 설정하는 것은 아닙니다. 로밍 메일 클라이언트에 대한 인증을 요구하거나 특정 사용자 계정을 제한하려면 적절한 인증 또는 메일 정책 제어 기능을 사용하십시오.

IP 허용 목록은 무엇을 제어하나요?

Zimbra의 MTA는 Postfix를 사용합니다. Postfix에서 발신 주소가 일치하는 클라이언트는 mynetworks릴레이를 위해 신뢰할 수 있는 클라이언트로 간주됩니다. Zimbra는 이 목록을 공개합니다 zimbraMtaMyNetworks. 목록에 있는 호스트는 인증 없이 외부 목적지로 메일을 보낼 수 있으므로 각 항목은 의미 있는 신뢰 결정입니다.

허용 목록과 릴레이 호스트를 혼동하지 마십시오 zimbraMtaRelayHost. 허용 ​​목록은 이 MTA를 통해 메시지를 릴레이할 수 있는 SMTP 클라이언트를 결정합니다. 릴레이 호스트는 MTA가 로컬이 아닌 메시지를 전달하는 업스트림 서버로, 예를 들어 네트워크 공급자가 스마트 호스트를 요구하는 경우에 사용됩니다. 둘 중 하나를 변경한다고 해서 다른 하나가 대체되는 것은 아닙니다.

Zimbra 기술 센터 페이지에서는 이 속성과 관련 명령에 대한 설명을 제공하지만, 일부 자료는 작업 진행 중이거나 보관 문서로 표시되어 있습니다. 변경 사항을 적용하기 전에 설치된 Zimbra 릴리스 및 배포 설계에 따라 동작이 올바른지 확인하십시오. 아래 예제에서는 Zimbra zimbra의 MTA 지침에 따라 Zimbra 명령줄 도구를 서비스 계정으로 사용합니다.

설정을 변경하기 전에

• 허용하려는 시스템에서 SMTP 요청을 수신하는 MTA 호스트를 식별하십시오. 여러 MTA가 있는 환경에서는 해당 연결을 처리하는 MTA를 파악하고 각 관련 서버에서 변경 사항을 계획하십시오.
• MTA가 실제로 인식하는 고정 소스 IP 주소를 찾으십시오. 애플리케이션이 NAT 뒤에 있는 경우 사설 LAN 주소가 아닌 공용 송신 주소를 사용하십시오. IP 주소가 자주 변경되는 경우 IP 주소만으로 구성된 허용 목록을 지속적으로 관리해야 합니다.
• 현재 Zimbra 속성과 유효한 Postfix 값을 기록하십시오. 기존 목록에 새 주소만 추가하기 전에 현재 항목에 의존하는 서비스가 무엇인지 확인하십시오.
• 사용하는 메일 서비스에 적합한 유지 관리 기간 또는 변경 기간을 설정하고, 원래 값과 동일한 복원용 사본을 보관하십시오.

/32IPv4 주소의 경우 와 같은 단일 호스트 CIDR을 사용하십시오 . 예를 들어 198.51.100.25/32는 하나의 IPv4 호스트를 나타냅니다. 이 주소는 예시일 뿐이며 실제 서버 주소로 복사해서는 안 됩니다. 와 같은 더 넓은 범위의 CIDR은 /24해당 서브넷의 모든 주소를 신뢰합니다. 테스트를 성공시키기 위해 공용 네트워크나 대규모 공급자 범위를 추가하지 마십시오.

Zimbra 릴레이 허용 목록을 설정하는 방법

1. 설정된 값과 유효 값을 검사합니다.

MTA 호스트에 로그인하고 Zimbra 서비스 계정으로 전환하세요. mta.example.com서버 이름은 설치 zmhostname명령에서 반환된 정확한 값으로 바꿔야 합니다.

su - zimbra
zmhostname
zmprov gs mta.example.com zimbraMtaMyNetworks
postconf mynetworks

첫 번째 쿼리는 Zimbra 서버 객체에 저장된 값을 읽어오고, postconfPostfix의 유효 설정을 보여줍니다. 두 출력값을 모두 저장하십시오. LDAP 속성이 설정되지 않은 경우 Postfix가 기본값을 사용할 수 있으므로, 빈 쿼리 결과가 신뢰할 수 있는 네트워크가 없다는 것을 의미하지 않습니다. 진행하기 전에 유효 값과 사용 중인 버전의 구성 동작을 확인하십시오.

2. 가장 작은 완전한 목록을 만드세요

루프백과 인증되지 않은 릴레이가 실제로 필요한 각 소스를 포함하는 목록을 만드세요. 로컬호스트와 하나의 고정된 애플리케이션 호스트에서만 릴레이를 수락해야 하는 서버의 경우 목록의 형태는 다음과 같습니다.

127.0.0.0/8 198.51.100.25/32

샘플 주소를 MTA에서 볼 수 있는 실제 주소로 교체하십시오. 서버에 필요한 로컬 인터페이스 또는 추가 신뢰 서비스는 필요한지 확인한 후에만 포함하십시오. 하나의 서버만 신뢰해야 하는 경우 광범위한 사무실 서브넷을 그대로 두지 말고, 가능한 경우 호스트 항목으로 축소하십시오.

3. 올바른 MTA에 값을 설정하십시오.

서버 수준 속성을 설정하는 데 사용합니다 zmprov ms. 이 명령은 값을 대체하므로 루프백을 포함하여 유지하려는 모든 항목을 포함해야 합니다.

zmprov ms mta.example.com zimbraMtaMyNetworks '127.0.0.0/8 198.51.100.25/32'

여러 IP 주소를 사용하는 경우, 승인된 IP 주소 목록 전체를 공백으로 구분하여 따옴표로 묶은 값 안에 입력하십시오. 샘플 명령어를 변경하지 않고 실행하지 마십시오. 설정이 전역 값, 서버 수준 재정의, IPv6, 여러 MTA 또는 버전별 동작에 의존하는 경우, 속성을 설정하기 전에 해당 배포 환경에서 상속 및 생성된 Postfix 구성이 어떻게 작동하는지 확인하십시오.

4. Postfix를 다시 시작하고 활성화된 설정을 확인합니다.

Zimbra 구성을 변경한 후에는 Zimbra 서비스 계정으로 Postfix를 다시 로드하고 유효 값을 다시 쿼리하십시오.

postfix reload
postconf mynetworks
zmprov gs mta.example.com zimbraMtaMyNetworks

출력 결과는 루프백을 포함하여 의도한 허용 목록과 일치해야 합니다. Postfix에서 네트워크 형식이 잘못되었거나 값이 다르다고 보고하는 경우, 메일 흐름 테스트를 시작하기 전에 해당 구성 문제를 해결하십시오. CIDR 항목은 올바른 네트워크 경계를 사용해야 합니다. 단일 호스트의 경우 /32인접 호스트를 포함하는 네트워크 마스크 대신 호스트 주소를 사용하십시오.

제한 기능이 제대로 작동하는지 확인하는 방법

실제 애플리케이션과 동일한 네트워크 경로 및 SMTP 수신기를 사용하는 제어되고 승인된 시스템에서 테스트하십시오. Zimbra 도메인 외부에 있는 사용자가 관리하는 사서함으로 메시지를 보내십시오. 승인된 호스트에서 메시지를 제출할 수 있는지, 그리고 MTA 로그에 성공적인 수신 또는 배달이 기록되는지 확인하십시오. Zimbra MTA 활동은 일반적으로 로그에 기록되므로 /var/log/zimbra.log메일 클라이언트의 성공 메시지에만 의존하지 말고 관련 타임스탬프와 소스 IP를 확인하십시오.

허용 목록에 없고 인증되지 않은 호스트에서 테스트해 보세요. 예상 결과는 로컬이 아닌 수신자에게 메일을 보내려고 할 때 릴레이 거부가 발생하는 것입니다. 거부된 연결과 Postfix에서 관찰된 소스 주소는 MTA 로그에서 확인하세요. 인증되지 않은 클라이언트도 로컬 Zimbra 수신자에게 메일을 보낼 수 있습니다. 이는 정상적인 메일 수신이며, 클라이언트가 발신 메일을 릴레이할 수 있다는 것을 증명하는 것은 아닙니다.

또한 이전 목록에 있던 정상적인 애플리케이션도 테스트하십시오. 애플리케이션 제출 실패는 일반적으로 잘못된 소스 주소가 허용 목록에 추가되었거나, 기존의 신뢰할 수 있는 종속성이 제거되었거나, 애플리케이션에 SMTP 인증이 필요한 경우를 의미합니다. 클라이언트가 네트워크 간에 로밍하거나 송신 IP가 불안정한 경우, IP 허용 목록을 반복적으로 변경하는 것보다 TLS를 통한 SMTP 인증을 사용하는 것이 일반적으로 관리하기 쉽습니다.

롤백 또는 문제 해결 방법

승인된 애플리케이션이 더 이상 전송하지 않으면 추측한 서브넷을 추가하는 대신 저장된 정확한 값을 복원하십시오. `--apply` 명령으로 적용 zmprov ms하고 Postfix를 다시 로드한 다음 `--apply` 명령으로 유효한 값을 확인하십시오 postconf mynetworks. 로드 밸런서, NAT 게이트웨이, 컨테이너 호스트 또는 아웃바운드 프록시가 MTA에 도달하기 전에 소스 주소를 변경하는지 확인하십시오.

응답 Relay access denied이 없다는 것은 클라이언트가 인증되지 않았거나 해당 소스 IP가 신뢰 목록에 없다는 의미일 수도 있습니다. 일반 이메일 사용자의 경우 모든 사용자 네트워크를 추가하는 대신 인증을 사용하여 SMTP 제출을 구성하십시오 zimbraMtaMyNetworks. 광범위한 허용 목록은 인증되지 않은 릴레이 표면을 넓혀 신뢰 네트워크에 관리되지 않는 장치가 포함된 경우 서버를 악용에 노출시킬 수 있습니다.

MTA 값이 올바르게 표시되지만 동작이 변경되지 않으면 연결을 수락한 서버를 수정했는지, 재부팅이 성공했는지, 그리고 다른 Postfix 인스턴스나 네트워크 장비가 SMTP를 처리하고 있지 않은지 확인하십시오. Zimbra에서 생성된 Postfix 파일을 직접 수정하는 것은 영구적인 해결책이 될 수 없습니다. 구성 관리 기능에 의해 파일이 다시 생성될 수 있습니다. LDAP 값과 런타임 구성이 일치하지 않는 경우 해당 릴리스의 Zimbra 관리 설명서 또는 지원 채널을 참조하여 릴리스별 절차를 확인하십시오.

성공적인 결과의 모습

• postconf mynetworks루프백 주소와 의도된 신뢰할 수 있는 소스 주소 또는 네트워크만 나열합니다.
• 승인되었지만 인증되지 않은 애플리케이션은 외부 테스트 사서함으로 메일을 보낼 수 있습니다.
• 인증되지 않았거나 승인되지 않은 호스트는 외부 수신자에 대한 릴레이 거부 응답을 받습니다.
• 인증된 사용자와 로컬 수신 메일은 정상적으로 작동합니다.
• 기록된 롤백 값과 종속 서비스 목록은 향후 변경을 위해 보존됩니다.

이 방법은 소스 IP를 기준으로 인증되지 않은 릴레이를 좁히는 데 유용합니다. SMTP 인증, TLS, 속도 제어, 계정 보안 또는 모니터링을 대체하는 것은 아니며, 하나의 공용 NAT 주소를 공유하는 개별 애플리케이션을 구분할 수도 없습니다. 따라서 이 방법은 특정 기능에 대한 제어 수단으로 활용하고, 네트워크 출력 또는 MTA 역할이 변경될 때마다 허용 목록을 검토해야 합니다.

출처

• 짐브라 기술 센터: ZimbraMtaMyNetworks
• 짐브라 테크 센터: 짐브라 MTA
• Zimbra 기술 센터: 메일 흐름 문제 식별 및 해결
• Postfix 매뉴얼: mynetworks