내 postfix는 나가는 릴레이 서버에 AUTH PLAIN을 보내지 않습니다. 며칠 전에는 효과가 있었겠지만 지금은 "릴레이가 허용되지 않음" 반송 메일을 받습니다.
메일 시스템은 postfix, fetchmail 및 dovecot을 사용하여 Alpine Linux VM에서 실행됩니다. Postfix는 비둘기장 라이브러리가 아닌 Cyrus SASL lib를 사용합니다.
main.cf 관련 부분:
relayhost = [RELAY_HOST]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/mailsrv/etc/postfix/sasl_passwd
smtp_sasl_security_options =
sasl_passwd:
[RELAY_HOST] USER:PASSWORD
tcpdump로 나가는 세션을 캡처했는데 AUTH PLAIN이 전송되지 않았습니다. 적절한 AUTH PLAIN 줄을 사용하여 텔넷으로 수동으로 메일을 보내는 것을 테스트했는데 제대로 작동했습니다.
그래서 내 해석은 postfix가 어느 시점에서는 SASL / AUTH PLAIN을 사용하기로 결정하지 않는다는 것입니다.
무엇이 문제일까요?
권한은 양호해야 하며, postmap이 호출되고, postfix가 다시 시작되고 다시 로드되고, libsasl이 설치되고 postfix가 cyrus로 빌드된 것으로 보고됩니다. 진부한 표현이라는 건 알지만 시스템은 며칠 전에는 작동했습니다. 로그에 표시되지 않는 일부 인증서 만료가 여기서 문제가 될 수 있습니까?
답변1
postfix는 AUTH PLAIN 라인을 생성하지 않는 HELO를 보냅니다.
HELO는 확장 협상 기능이 없는 원래의 핸드셰이크 명령입니다. 클라이언트가 SASL을 사용하려면 먼저 EHLO(extended-hello)를 보내고 서버가광고하다원하는 SASL 메커니즘.
기본적으로 Postfix를 포함한 많은 SMTP 클라이언트는 "ESMTP"가 서버의 인사말 배너(예: 220 foo.example.com ESMTP Sendmail
)에 나타납니다. ESMTP를 지원하지 않는 서버는 SASL도 지원하지 않는 것으로 간주됩니다.
서버의 인사말이 올바른 경우 실수로
smtp_never_send_ehlo
또는 옵션을 활성화하지 않았는지 확인하십시오.smtp_pix_workarounds
서버의 인사말이 잘못되었음에도 불구하고 EHLO를 허용하는 경우
smtp_always_send_ehlo = yes
Postfix 구성에서 활성화하여 EHLO를 강제로 사용할 수 있습니다.
서버를 관리하는 경우 인사말을 수정해 보세요. 이는 다른 도메인에서 들어오는 메시지 전달에도 영향을 미칠 수 있습니다. 예를 들어 ESMTP가 없으면 기회주의적인 STARTTLS도 없습니다.
예를 들어 서버가 Postfix도 실행 중인 경우 smtpd_banner
옵션에 "ESMTP"를 포함해야 합니다.
smtpd_banner = $myhostname ESMTP $mail_name
(STARTTLS 사용을 금지하기 위해 이 방법을 사용하는 스팸 방지 게이트웨이를 통해 연결이 진행될 수도 있습니다. 단순히 EHLO 응답에서 이를 제거하는 대신 EHLO 자체를 금지하려고 시도합니다.)
일반적으로 포트 25는 메시지 수신(다른 도메인으로부터의 인바운드 전달) 전용입니다. 587 또는 465는 메시지 "제출"(클라이언트에서 아웃바운드)용 포트입니다.
따라서 Postfix가 로컬 클라이언트로 작동하는 경우(릴레이 호스트가 있고 인증을 사용하기 때문에) 대신 포트 587에서 릴레이 호스트에 연결해야 합니다.
포트 465에 연결하려면 smtp_tls_wrappermode = yes
처음부터 TLS를 사용하므로 가 필요합니다. (이것은 실제로 방화벽이 핸드셰이크를 변조하는 것을 방지하므로 이점이 있습니다.)
포트 587을 사용하는 경우 TLS는 선택 사항이지만('STARTTLS' 명령을 통해서만 활성화됨)정말로 그래야 한다서버가 TLS를 지원하는 경우 TLS 사용을 시행합니다. 그렇게 하려면 을 설정하십시오 smtp_tls_security_level = verify
.