접미사 smtp 및 제출 혼동

이메일 클라이언트가 아웃 바운드 메일에 포트 465 (smtps)를 사용하도록 postfix를 설정했습니다. smtps (포트 465)와 제출 (포트 587)의 차이점을 실제로 이해하지 못합니다.

클라이언트가 안전하게 메일을 보내도록 postfix를 구성 할 때 '모범 사례'는 무엇입니까? smtps 만 사용 하시겠습니까? 아니면 제출과 smtp를 모두 사용 하시겠습니까?

포트 465는 SSL로 보안 된 SMTP 연결에 사용되었습니다. 그러나 STARTTLS : "smtps TCP 포트 해지" 의 가용성으로 인해 SMTP에 해당 포트를 사용하는 것이 더 이상 사용되지 않습니다. 요즘에는 더 이상 SMTPS에 포트 465를 사용하지 않아야합니다. 대신 포트 25를 사용하여 다른 서버에서 도메인의 메일을 받거나 포트 587을 사용하여 서버에서 다른 도메인 및 다른 서버로 메일을 보내야하는 클라이언트에서 전자 메일을받습니다.

추가로 포트 587은 메일 제출 전용이며 메일 제출은 메시지를 변경하거나 인증을 제공하도록 설계되었습니다.

• 메일을 제출하려는 클라이언트에 대한 인증 제공 및 요구
• 원하지 않는 대량 메일 (스팸) 또는 감염된 메일 (바이러스 등)의 제출을 ​​방지하는 보안 메커니즘 제공
• 메일을 조직의 요구에 맞게 수정 (보낸 사람 등)

포트 587 로의 제출은 STARTTLS를 지원해야하므로 암호화 될 수 있습니다. RFC # 6409 도 참조하십시오 .

TL; DR

새로운 권장 사항은 제출 / smtps 및 STARTTLS 제출 을 한동안 지원하여 더 이상 사용되지 않으면 나중에 폐기하는 것입니다. POP3 대 POP3S 및 IMAP 대 IMAPS에도 동일한 권장 사항이 적용됩니다.

세부

모범 사례는 RFC 8314 섹션 3.3으로 변경되었습니다 .

"submissions"서비스 (기본 포트 465)에 대한 TCP 연결이 설정되면 TLS 핸드 셰이크가 즉시 시작됩니다. […]

포트 587의 STARTTLS 메커니즘은 포트 465의 상황 (섹션 7.3에서 논의 됨)으로 인해 비교적 광범위하게 배포됩니다. 이는 Implicit TLS가 STARTTLS보다 서버에 더 널리 배포되는 IMAP 및 POP 서비스와 다릅니다. 일관성과 부록 A 에서 논의 된 추가적인 이유 때문에 시간이 지남에 따라 MUA 소프트웨어에서 사용하는 핵심 프로토콜을 암시 적 TLS로 마이그레이션하는 것이 바람직합니다 . 그러나 제출에 암호화 사용을 최대화하려면 몇 년의 전환 기간 동안 TLS를 통한 메시지 제출 메커니즘을 모두 지원하는 것이 바람직합니다. 결과적으로 클라이언트와 서버는이 전환 기간 동안 포트 587에서 STARTTLS와 포트 465에서 암시 적 TLS를 모두 구현해야합니다.. 구현이 올 바르고 클라이언트와 서버가 메시지 제출 전에 TLS의 성공적인 협상을 요구하도록 구성된 경우 포트 587의 STARTTLS 보안 포트와 포트 465의 암시 적 TLS 사이에는 큰 차이가 없습니다.

인용 된 부록 A 는 모든 SMTP, POP3 및 IMAP에 대해 암시 적 TLS를 선호하는 결정에 대해 자세히 설명합니다.

1. 우리는 어쨌든 모든 곳에서 암호화 된 연결 만을 원 하므로 실제로 호환성이 사용되지 않을 때 이러한 모든 프로토콜의 이전 버전과 호환되는 버전을 유지할 필요가 없습니다.
2. 여러 구현에서 동일한 문제로 인해 STARTTLS 협상 단계가 악용되었습니다.