Sự khác biệt giữa các cổng 465 và 587 là gì?

245

Các cổng 465 và 587 này đều được sử dụng để gửi thư (gửi thư) nhưng sự khác biệt thực sự giữa chúng là gì?

email  smtp  port  postfix-mta  email-client 
— Ilia Rostovtsev
nguồn
1
Sự khác biệt duy nhất là các tiêu chuẩn chính thức và cổng 465 là để hỗ trợ di sản?
— Ilia Rostovtsev
"Tên dịch vụ và đăng ký số cổng giao thức vận chuyển" của iana là hướng dẫn chính thức cho việc sử dụng cổng được khuyến nghị; việc sử dụng 465 cho SMTP qua SSL là không chính thức. Đọc về Cổng trong SMTP . Việc sử dụng chính thức của iana không phải lúc nào cũng giống nhau cho cả giao thức truyền tải TCP và UDP. NB: nếu bạn là quản trị viên máy chủ SMTP , BẠN kiểm soát (các) cổng nào được sử dụng; nếu bạn là khách hàng , bạn chỉ nhận được các cổng có sẵn cho bạn.
— gerryLowry
— Ciro Santilli郝海东冠状病六四事件法轮功
— Rick

Câu trả lời:

235

Giao thức SMTP: smtps (cổng 465) v. Msa (cổng 587)

Các cổng 465 và 587 được dành cho ứng dụng email đến máy chủ email - gửi email bằng giao thức SMTP.

Cổng 465 dành cho smtps
Mã hóa SSL được khởi động tự động trước khi có bất kỳ giao tiếp cấp SMTP nào.

Cổng 587 dành cho msa
Nó gần giống như cổng SMTP tiêu chuẩn. MSA nên chấp nhận email sau khi xác thực (ví dụ: sau SMTP AUTH). Nó giúp ngăn chặn thư rác đi khi các quản trị viên của phạm vi DUL có thể chặn các kết nối gửi đến cổng SMTP (cổng 25).
Mã hóa SSL có thể được bắt đầu bằng lệnh STARTTLS ở cấp độ SMTP nếu máy chủ hỗ trợ và ISP của bạn không lọc trả lời EHLO của máy chủ (báo cáo 2014) .

Cổng 25 được sử dụng bởi giao tiếp MTA đến MTA (máy chủ thư đến máy chủ thư). Nó có thể được sử dụng để liên lạc giữa máy khách với máy chủ nhưng hiện tại nó không được khuyến nghị nhất. Cổng SMTP tiêu chuẩn chấp nhận email từ các máy chủ thư khác đến hộp thư "nội bộ" mà không cần xác thực .

— AnFi
nguồn
7
Cổng SMTP tiêu chuẩn chấp nhận email từ máy chủ thư khác mà không cần xác thực - thực sự không chính xác về mặt kỹ thuật. Cổng 25 tiêu chuẩn có thể chuyển thư cả bằng cách sử dụng xác thực và không phụ thuộc vào cấu hình của MTA.
— Ilia Rostovtsev
2
@ Cổng tiêu chuẩn SMTP của MTA thông thường không thể từ chối (tất cả) các kết nối SMTP chưa được xác thực.
— AnFi
1
Làm thế nào về Postfix? Nó không cho phép chuyển tiếp thư theo mặc định mà chỉ cho các kết nối từ cùng một mạng ?
— Ilia Rostovtsev
4
@Ilia Ngoài ra còn có thư đến các tên miền email địa phương.
— AnFi
6
Lưu ý rằng mặc dù không chính thức, cổng 465 cung cấp cho người dùng cuối đảm bảo hơn rằng họ thực sự đang nói chuyện qua một kênh được mã hóa. Cổng 587, với TLS là tùy chọn, có nghĩa là người dùng cuối có thể cung cấp thông tin đăng nhập của họ qua kênh không được mã hóa. Với các ứng dụng email là chính họ, bạn không thể đảm bảo MUA thậm chí sẽ cảnh báo người dùng rằng kết nối đã bị hạ cấp.
— sporker
132

587 so với 465

Các bài tập cổng này được chỉ định bởi Cơ quan cấp số được gán Internet (IANA) :

  • Cổng 587 : [SMTP] Gửi tin nhắn (SMTP-MSA), một dịch vụ chấp nhận gửi email từ các ứng dụng email (MUA). Được mô tả trong RFC 6409.
  • Cổng 465 : Thư mục kết xuất URL cho SSM (hoàn toàn không liên quan đến email)

Về mặt lịch sử, cổng 465 được lên kế hoạch ban đầu cho SMTPS mã hóa và xác thực “wrapper” qua SMTP, nhưng nó đã nhanh chóng bị phản đối (trong vòng vài tháng, và hơn 15 năm trước) ủng hộ STARTTLS qua SMTP (RFC 3207). Mặc dù thực tế đó, có lẽ có nhiều máy chủ hỗ trợ trình bao bọc giao thức không dùng nữa, chủ yếu để hỗ trợ các máy khách cũ đã triển khai SMTPS. Trừ khi bạn cần hỗ trợ các khách hàng lớn tuổi như vậy, SMTPS và việc sử dụng nó trên cổng 465 sẽ không có gì khác hơn là một chú thích lịch sử.

Thuật ngữ vô vọng và khó hiểu, SSL , thường được sử dụng để chỉ ra trình bao bọc SMTPS và TLS để chỉ ra phần mở rộng giao thức STARTTLS .

Để hoàn thiện: Cổng 25

  • Cổng 25 : Chuyển thư đơn giản (SMTP-MTA), một dịch vụ chấp nhận gửi email từ các máy chủ khác (MTA hoặc MSA). Được mô tả trong RFC 5321.

Nguồn:

— danorton
nguồn
1
giải thích kỹ thuật tốt đẹp, đã tìm kiếm SSL vs TLS.
— kiranking
11
SMTPS and its use on port 465 should remain nothing more than an historical footnote. Ngoại trừ việc Gmail và hầu hết các nhà cung cấp email khác sử dụng Cổng 465 cho SSL hay còn gọi là SMTPS. Đó là một thực tế không đi đến đâu, bất kể IANA chỉ định điều gì.
— Eric J.
6
@EricJ. ... Nhưng gmail cũng hỗ trợ cổng 587. Bạn có biết Google sử dụng cổng nào trong nội bộ không? Mặt khác, thực tế là họ hỗ trợ 465 không thực sự được coi là bằng chứng mà nó được ưa thích hoặc thậm chí đặc biệt được sử dụng.
— Bắn Parthian
2
Vâng, chúng tôi đang ở năm 2018 và tôi thấy không có cổng nào trở thành lịch sử. 456vẫn đang được sử dụng bởi những người chơi lớn Ngoài ra, tôi sẽ chỉnh sửa câu trả lời của mình để phản ánh rằng IANA là một mớ hỗn độn và họ vẫn không đồng ý nếu họ nên sử dụng 456hay không - RFC 8314 tools.ietf.org/html/rfc8314#page-6 - When a TCP connection is established for the "submissions" service (default port 465), a TLS handshake begins immediately- RFC này được tham chiếu bởi Liên kết "Cổng 456" :) - ngày đăng ký: 2017-12-12
1
Chính tả "Rendezvous" hiện đã được sửa tại iana.org
— arni
19

Câu trả lời chính xác cho câu hỏi này đã được thay đổi bằng việc xuất bản RFC 8314 . Do đó, cổng 465 và 587 đều là các cổng hợp lệ cho tác nhân gửi thư (MSA). Cổng 465 yêu cầu đàm phán TLS / SSL khi thiết lập kết nối và cổng 587 sử dụng STARTTLS nếu một người chọn đàm phán TLS. Sổ đăng ký IANA đã được cập nhật để cho phép sử dụng hợp pháp cổng 465 cho mục đích này. Đối với chuyển tiếp thư, chỉ có cổng 25 được sử dụng vì vậy STARTTLS là cách duy nhất để thực hiện TLS với chuyển tiếp thư. Thật hữu ích khi nghĩ về chuyển tiếp thư và gửi thư là hai dịch vụ rất khác nhau (có nhiều khác biệt về hành vi như yêu cầu xác thực, thời gian chờ khác nhau, quy tắc sửa đổi thư khác nhau, v.v.) xảy ra để sử dụng giao thức dây tương tự.

— Chris
nguồn
Nó là tốt hơn để sử dụng cổng 465 hoặc 587?
— Aaron Franke
Nếu bạn đang chạy một dịch vụ SMTP công cộng: cả hai đều tương thích. Nếu nó là riêng tư, hãy chọn TLS tiềm ẩn trên 465 trừ khi bạn phải hỗ trợ các máy khách không hỗ trợ nó. Đoạn trích hỗ trợ: "Tuy nhiên, để tối đa hóa việc sử dụng mã hóa để gửi, mong muốn hỗ trợ cả hai cơ chế Gửi tin nhắn qua TLS trong thời gian chuyển tiếp trong vài năm. Do đó, khách hàng và máy chủ NÊN triển khai cả STARTTLS trên cổng 587 và TLS tiềm ẩn trên cổng 465 cho giai đoạn chuyển tiếp này " tools.ietf.org/html/rfc8314#section-3.3
— Alain O'Dea
4

Cổng 465: IANA đã chỉ định lại một dịch vụ mới cho cổng này và nó không còn được sử dụng cho giao tiếp SMTP.

Tuy nhiên, vì đã từng được IANA công nhận là hợp lệ, nên có thể có các hệ thống kế thừa chỉ có khả năng sử dụng phương thức kết nối này. Thông thường, bạn sẽ chỉ sử dụng cổng này nếu ứng dụng của bạn yêu cầu. Tìm kiếm nhanh trên Google và bạn sẽ tìm thấy nhiều bài viết về ISP tiêu dùng đề xuất cổng 465 là thiết lập được đề xuất. Hy vọng điều này kết thúc sớm! Nó không tuân thủ RFC.

Cổng 587: Đây là cổng gửi thư mặc định. Khi một ứng dụng thư hoặc máy chủ gửi một email được định tuyến bởi một máy chủ thư thích hợp, nó sẽ luôn sử dụng cổng này.

Mọi người nên xem xét sử dụng cổng này như mặc định, trừ khi bạn bị chặn rõ ràng bởi mạng ngược dòng hoặc nhà cung cấp dịch vụ lưu trữ. Cổng này, cùng với mã hóa TLS, sẽ đảm bảo email được gửi an toàn và tuân theo các nguyên tắc do IETF quy định.

Cổng 25: Cổng này tiếp tục được sử dụng chủ yếu để chuyển tiếp SMTP. Chuyển tiếp SMTP là việc truyền email từ máy chủ email đến máy chủ email.

Trong hầu hết các trường hợp, các máy khách SMTP hiện đại (Outlook, Mail, Thunderbird, v.v.) không nên sử dụng cổng này. Theo truyền thống, các nhà cung cấp dịch vụ ISP và nhà cung cấp dịch vụ lưu trữ đám mây theo truyền thống sẽ bị chặn để hạn chế lượng thư rác được chuyển tiếp từ các máy tính hoặc máy chủ bị xâm nhập. Trừ khi bạn đặc biệt quản lý một máy chủ thư, bạn sẽ không có lưu lượng truy cập qua cổng này trên máy tính hoặc máy chủ của bạn.

— Tương tự S
nguồn
1

Tôi không muốn đặt tên, nhưng ai đó dường như hoàn toàn sai. Cơ quan tiêu chuẩn được tham chiếu đã nêu như sau: đệ trình 465 tcp Gửi tin nhắn qua giao thức TLS [IESG] [IETF_Chair] 2017-12-12 [RFC8314]

Nếu bạn rất có khuynh hướng, bạn có thể muốn đọc RFC được tham chiếu.

Điều này dường như ngụ ý rõ ràng rằng cổng 465 là cách tốt nhất để buộc truyền thông được mã hóa và chắc chắn rằng nó được đặt đúng chỗ. Cổng 587 không đảm bảo như vậy.

— Người tìm kiếm
nguồn
Tại sao tốt hơn là sử dụng cổng 465?
— Aaron Franke
1

Tôi sử dụng cổng 465 mọi lúc.

Câu trả lời của danorton đã lỗi thời. Như ông và Wikipedia nói, cổng 465 ban đầu được lên kế hoạch cho mã hóa SMTPS và nhanh chóng bị từ chối 15 năm trước. Nhưng nhiều ISP vẫn đang sử dụng cổng 465, đặc biệt là tuân thủ các khuyến nghị hiện tại của RFC 8314 , khuyến khích sử dụng TLS ẩn thay vì sử dụng lệnh STARTTLS với cổng 587. (Xem phần 3.3 ). Sử dụng cổng 465 là cách duy nhất để bắt đầu một phiên bảo mật hoàn toàn với máy chủ SMTP hoạt động như một tác nhân gửi thư (MSA).

Về cơ bản, những gì RFC 8314 khuyến nghị là các trao đổi email rõ ràng bị bỏ qua và tất cả ba giao thức thư IETF phổ biến chỉ được sử dụng trong các phiên TLS ngầm để đảm bảo tính nhất quán khi có thể. Các cổng bảo mật được đề xuất, sau đó, lần lượt là 465, 993 và 995 cho SMTPS, IMAP4S và POP3S.

Mặc dù RFC 8314 chắc chắn cho phép tiếp tục sử dụng TLS rõ ràng với cổng 587 và lệnh STARTTLS, nhưng làm như vậy sẽ mở ra tác nhân người dùng thư (MUA, ứng dụng thư) để hạ cấp tấn công trong đó một kẻ trung gian chặn STARTTLS yêu cầu nâng cấp lên bảo mật TLS nhưng từ chối nó, do đó buộc phiên phải ở trong văn bản rõ ràng.

— HJJ
nguồn
4
Anh ấy đúng. Chỉ vì các ISP lạm dụng nó và chưa cập nhật tài liệu của họ không làm cho nó không chính xác. Anh ta đã không nói rằng nó không được sử dụng - chỉ là nó không phải là một hoạt động tuân theo RFC. Nói cách khác, bạn nên sử dụng 25 và 587 với email và chỉ sử dụng 465 nếu bạn CÓ, vì một số lý do.
— dodexahedron
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.