Postfix smtps ve gönderme karışıklığı


13

E-posta istemcilerinin giden postalar için bağlantı noktası 465 (smtps) kullanması için postfix'i kurdum. Smtps (465 numaralı bağlantı noktası) ile gönderim (587 numaralı bağlantı noktası) arasındaki farkı gerçekten anlamıyorum.

İstemcileri güvenli bir şekilde posta göndermek için postfix'i yapılandırırken 'en iyi uygulama' nedir? Sadece smtps mi kullanıyorsunuz? Veya hem gönderim hem de smtps kullanıyor musunuz?

Yanıtlar:


21

465 numaralı bağlantı noktası SSL ile güvenli SMTP bağlantıları için kullanıldı. Ancak, SMTP için bu bağlantı noktasını kullanmak STARTTLS kullanılabilirliğiyle kullanımdan kaldırılmıştır: "smtps TCP bağlantı noktasını iptal etme" Bu günlerde SMTPS için artık 465 numaralı Bağlantı Noktası'nı kullanmamalısınız. Bunun yerine, diğer sunuculardan alan adınız için posta almak üzere Bağlantı Noktası 25'i veya sunucunuz üzerinden başka etki alanlarına ve dolayısıyla diğer sunuculara posta göndermesi gereken istemcilerden e-posta almak için bağlantı noktası 587'yi kullanın.

Bununla birlikte, ek bir not olarak, 587 numaralı bağlantı noktası posta gönderme işlemine ayrılmıştır - ve posta gönderme iletiyi değiştirmek ve / veya kimlik doğrulama sağlamak üzere tasarlanmıştır:

  • posta göndermeye çalışan müşteriler için kimlik doğrulaması teklif etme ve gerektirme
  • istenmeyen toplu posta (spam) veya virüslü postaların (virüsler, vb.) gönderilmesini önlemek için güvenlik mekanizmaları sağlamak
  • postayı bir kuruluşun ihtiyaçlarına göre değiştirme (bölümü yeniden yazma vb.)

587 numaralı bağlantı noktasına gönderimin STARTTLS'yi desteklemesi beklenir ve bu nedenle şifrelenebilir. Ayrıca bkz . RFC # 6409 .


Cevabınız için teşekkürler, postfix ile gönderimi başarıyla ayarladım ve şimdi işler çok daha net. :-)
Aditya K

Hoş geldiniz =)
liquidat

1
465 bağlantı noktasındaki trafik tamamen şifrelenmiştir. Starttls kullandığınızda, istemci güvenli aktarım girebilir ve şifreleme olmadan veri göndererek ondan çıkabilir. serverfault.com/q/523804/201912
QkiZ

2

TL; DR

Yeni öneri hem destek olmaktır gönderimler / SMTPS ve teslim artık kullanılmadığı zamanlar sonradan kaldırıyorsunuz, zaman varlık için STARTTLS ile. (Aynı öneriler POP3 ile POP3S ve IMAP ile IMAPS için de geçerlidir.)

ayrıntılar

En iyi uygulama RFC 8314 Bölüm 3.3 ile değişmiştir :

"Gönderimler" hizmeti (varsayılan bağlantı noktası 465) için bir TCP bağlantısı kurulduğunda, TLS anlaşması hemen başlar. [...]

Bağlantı noktası 587'deki STARTTLS mekanizması, bağlantı noktası 465'teki durum nedeniyle nispeten yaygın bir şekilde konuşlandırılmıştır (Bölüm 7.3'te ele alınmıştır). Bu, Örtülü TLS'nin STARTTLS'den daha çok sunuculara dağıtıldığı IMAP ve POP hizmetlerinden farklıdır. MUA yazılımı tarafından kullanılan temel protokollerin tutarlılık ve Ek A'da tartışılan ek nedenler için zaman içinde Örtülü TLS'ye taşınması arzu edilir . Ancak, gönderme için şifreleme kullanımını en üst düzeye çıkarmak için, TLS üzerinden Mesaj Gönderme için her iki mekanizmanın da birkaç yıllık bir geçiş dönemi boyunca desteklenmesi arzu edilir. Sonuç olarak, istemciler ve sunucular bu geçiş dönemi için hem 587 numaralı bağlantı noktasında STARTTLS'yi hem de 465 numaralı bağlantı noktasında Örtülü TLS'yi uygulamalıdır. Uygulamalar doğruysa ve hem istemci hem de sunucu İleti Gönderimi öncesinde başarılı TLS anlaşması gerektirecek şekilde yapılandırılmışsa, bağlantı noktası 587'de STARTTLS ile bağlantı noktası 465'te Örtülü TLS arasında önemli bir fark olmadığını unutmayın.

Atıfta bulunulan Ek A daha sonra tüm SMTP, POP3 ve IMAP için örtük TLS'yi tercih etme kararı üzerinde durmaktadır, çünkü bu ana noktalar

  1. Biz istiyoruz sadece pratikte compatiblity kullanılmadığını zaman, bütün bu protokollerin bir geriye dönük olarak uyumlu bir sürümünü korumada anlamı yok, her yerde her durumda şifreli olan bağlantıları
  2. Çeşitli uygulamalardaki özdeş sorunlar nedeniyle STARTTLS müzakere safhasında istismarlar oldu
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.