이것은 실제로 어느 곳에서나 명시 적으로 정의되어 있지 않으며, 서버의 “신뢰”여부는 클라이언트 (물론 다른 메일 서버 일 수 있음)에 연결된 서버에 따라 다릅니다. 관련 RFC에서 인용 ( RFC 2487 ) :

SMTP 클라이언트가 인증 또는
개인 정보 수준이 계속하기에 충분하지 않다고 판단
하면 TLS 협상이 완료된 직후에 SMTP QUIT 명령을 실행해야합니다.
SMTP 서버가 인증 또는
프라이버시 수준이 계속하기에 충분하지 않다고 판단
하면 554 응답 코드 (예 : 텍스트 문자열
)를 사용
하여 클라이언트의 모든 SMTP 명령 (QUIT 명령 제외)에 응답해야합니다. ”
보안 부족으로 인해 명령이 거부되었습니다”).

TLS 협상에서 상대방 의 진위 여부에 대한 결정은 현지 문제입니다. 그러나
결정에 대한 몇 가지 일반적인 규칙은 다음과 같습니다.

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

이것이 기본적으로 의미하는 것은 서버가 주어진 인증서를 사용하여 TLS 암호화를 제공 할 때 인증서 수락 또는 거부에 대한 결정은 전적으로 다른 부분에 달려 있으며 인증서의 이름이 연결된 것과 동일하기를 원할 것 입니다. 일치하지 않더라도 아주 잘 받아들입니다.

그러나 더 많은 것이 있습니다. 동일한 RFC에서 다시 인용 :

TLS 핸드 셰이크가 완료되면 SMTP 프로토콜이
초기 상태 (서버에서 220
서비스 준비 인사말을 발행 한 후 SMTP의 상태 )로 재설정됩니다 . 서버
는 TLS 협상 자체에서 얻지 못한
EHLO 명령에 대한 인수와 같이 클라이언트에서 얻은 모든 지식을 폐기해야
합니다. 클라이언트
는 TLS
협상 자체 에서 얻지 못한 SMTP 서비스 확장
목록과 같이 서버에서 얻은 모든 지식을 폐기해야 합니다. 클라이언트는
성공적인 TLS 협상 후 EHLO 명령을 첫 번째 명령 으로 보내야합니다 .

따라서 TLS 핸드 셰이크 이전 의 HELO / EHLO에 대한 서버의 말은 실제로 중요하지 않은 것 같습니다.

필자의 경험에 따르면 자체 서명 인증서는 인터넷 연결 메일 서버에서 잘 작동합니다. 즉, 다른 메일 서버는 인증서 확인에도 신경 쓰지 않으며 발급에 관계없이 TLS 암호화를 제공 할 수있는 모든 것을 행복하게 받아들입니다. 권한 또는 주제 이름.

답변

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others