전달을 위해 대기 중인 이메일에 대해 조치를 취하는 방법
소개
이 문서에서는 ESA(Email Security Appliance)에 보류되어 전달 보류 중인 이메일 전달을 위해 대기된 문제 해결에 수행할 수 있는 작업에 대해 설명합니다.
사전 요구 사항
- ESA에 대한 CLI 액세스
- CES(Cloud Email Security) 고객의 경우 CLI 액세스에 대한 자세한 정보는 여기에서 확인할 수 있습니다.
- ESA에 대한 GUI 액세스
무슨 뜻이죠?
이메일 전달과 관련된 문제를 해결할 때 메시지 추적 또는 메일 로그에서 메시지의 마지막 상태가 전달 대기열에 있음을 확인할 수 있습니다.이는 메시지가 ESA에서 처리되었지만, 어떤 이유로 ESA에서 next-hop MTA로 메시지 전달을 완료할 수 없음을 의미합니다.이는 여러 가지 이유로 인해 발생할 수 있지만, 일반적으로 ESA가 대상 호스트에 연결할 수 없거나 다음 홉의 MTA에 의해 메시지가 제한되거나 거부되기 때문입니다.
검토 및 문제 해결
아래 단계는 전달 대기열에 있는 메시지를 자세히 살펴보고 SMTP 연결 문제를 해결하는 프로세스를 안내합니다.
1단계 - 배달 보류 중인 메시지 수 확인
CLI에서 Active Recipients별로 정렬된 tophosts 명령을 사용하여 전달 대기열에 있는 항목을 검토할 수 있습니다.Active Recipients(활성 수신자)는 전달 대기 중인 메시지 수를 나타냅니다.
esa.lab.local> tophosts active_rcpts
Status as of: Thu Aug 13 14:29:42 2020 EDT
Hosts marked with '*' were down as of the last delivery attempt.
Active Conn. Deliv. Soft Hard
# Recipient Host Recip. Out Recip. Bounced Bounced
1 the.encryption.queue 0 0 0 0
2 the.euq.queue 5 0 0 0 0
3 the.euq.release.queue 0 0 0 0 0
GUI에서 Monitor(모니터링) > Delivery Status(전달 상태)로 이동할 수 있습니다.
2단계 - 대상 도메인의 호스트 상태 확인
CLI에서 hoststatus 명령을 해당 도메인과 함께 사용하여 Host up/down 상태를 검토할 수 있습니다.출력에 대한 자세한 내용은 다음을 참조하십시오.여기.
esa.lab.local> hoststatus gmail.com
Host mail status for: 'gmail.com'
Status as of: Thu Aug 13 14:37:17 2020 EDT
Host up/down: up
Counters:
Queue
Soft Bounced Events 0
Completion
Completed Recipients 336
Hard Bounced Recipients 0
DNS Hard Bounces 0
5XX Hard Bounces 0
Filter Hard Bounces 0
Expired Hard Bounces 0
Other Hard Bounces 0
Delivered Recipients 336
Deleted Recipients 0
Gauges:
Queue
Active Recipients 0
Unattempted Recipients 0
Attempted Recipients 0
Connections
Current Outbound Connections 0
Pending Outbound Connections 0
GUI에서 Monitor(모니터) > Delivery Status(전달 상태) 아래에서도 이를 볼 수 있습니다.
Host up/down 상태의 일부 예 및 의미할 수 있는(모든 포함 아님):
up - 연결 가능하며 능동적으로 메시지 수락
down - 양방향으로 다운됨(예: 연결이 거부되었거나 호스트에 대한 경로가 없음) 또는 SMTP 대화가 시간 초과됨
unknown -연결할 수 없음(예: 잘못된 인터페이스를 통해 라우팅된 전달 또는 인터페이스의 IP 주소가 NAT가 제대로 NAT/방화벽을 통해 라우팅되지 않음)
3단계 - SMTP 연결 테스트
호스트에 연결할 수 없는 경우 먼저 dig를 사용하여 DNS MX 레코드를 확인한 다음 텔넷을 사용하여 연결을 테스트할 수 있습니다.
esa.lab.local> dig mx gmail.com
;; QUESTION SECTION:
;gmail.com. IN MX
;; ANSWER SECTION:
gmail.com. 1784 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 1784 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 1784 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 1784 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 1784 IN MX 20 alt2.gmail-smtp-in.l.google.com.
esa.lab.local> telnet alt1.gmail-smtp-in.l.google.com 25
Trying 64.233.186.26...
Connected to cb-in-f26.1e100.net.
Escape character is '^]'.
220 mx.google.com ESMTP d21si4412123pll.407 - gsmtp
텔넷에서 Connected 및 220 배너를 반환하면 delivernow all 명령을 사용하여 또는 GUI에서 Monitor(모니터) > Delivery Status(전달 상태)로 이동하고 Retry All Delivery(모든 전달 재시도)를 클릭할 수 있습니다.
연결 테스트가 거부를 반환하면 추가 트러블슈팅이 필요할 수 있습니다.메일 로그 및/또는 메시지 추적을 검토하여 가능한 거부 사유가 표시되는지 확인합니다.
추가 문제 해결 방법
- 테스트 메시지를 보내는 데 SMTPPING을 사용할 수 있습니다.자세한 내용을 보려면 여기를 클릭하십시오.
- 패킷 캡처를 사용하면 SMTP 대화를 검토하고 오류가 있는지 확인(예: TLS)할 수 있습니다. 자세한 내용을 보려면 여기를 클릭하십시오. CES 고객은 캡처를 실행하는 데 도움이 필요하면 Cisco TAC에 문의해야 합니다.
- Domain Debug Logs(도메인 디버그 로그)는 SMTP 대화의 존재를 보여주며, ESA에서 메시지를 전달하는 방법을 확인해야 하는 경우 매우 유용합니다.자세한 내용을 보려면 여기를 클릭하십시오.
피드백