Ověření SMTP - SMTP Authentication - Wikipedia

Ověření SMTP, často zkráceně SMTP AUTH, je rozšířením Protokol jednoduchého přenosu pošty (SMTP), přičemž se klient může přihlásit pomocí jakéhokoli ověřovacího mechanismu podporovaného serverem. Používají ho hlavně podání servery, kde je ověřování povinné.[1]

Dějiny

SMTP podle specifikace Jon Postel v 70. letech nezajistil používání hesel pro odesílání e-mailových zpráv; každý server byl záměrně otevřený přenos pošty. Jako výsledek, spam a červi, ačkoli to původně nebyl problém, se koncem 90. let stal morem.[2] Před SMTP AUTH, a předat klienta musel být identifikován IP adresa, což je praktické pouze pro e-mailové služby poskytované stejným serverem poskytovatel internetu (ISP) dodávající připojení nebo jinak využívající konkrétní hacky, jako je POP před SMTP.

John Gardiner Myers zveřejnil první koncept SMTP AUTH v roce 1995,[3] a to bylo postupně vyvíjeno a diskutováno v IETF spolu s protokolem pro odeslání pošty, Rozšířený SMTP (ESMTP) a Jednoduché ověřování a vrstva zabezpečení (SASL). Starší mechanismus SASL pro ověřování ESMTP (ESMTPA) je CRAM-MD5 a použití MD5 algoritmus v HMAC (ověřovací kódy založené na hash zpráv) jsou stále považovány za zdravé.[4]

The Konsorcium pro internetovou poštu (IMC) uvedlo, že 55% poštovních serverů byla v roce 1998 otevřená relé,[5] ale méně než 1% v roce 2002.[6]

Role v systému přenosu pošty

Používat agent pro odesílání pošty (MSA), obvykle na portu 587, implikuje SMTP AUTH. Použití softwaru MSA je podporováno většinou softwaru[7] a je doporučeno, zejména pro podporu kočovných uživatelů, protože několik síťových rozbočovačů blokuje nebo používá port 25 SMTP proxy. MSA odpovídá za zajištění toho, aby obálka zprávy obsahovala dobré adresy, a může prosazovat místní zásady pro Z pole záhlaví. Ověření, že odesílatel obálky (aka Zpáteční cesta) používá SPF a Z adresa souhlasí s ověřeným uživatelské ID je zvláště důležité pro domény, které podepisují zprávy pomocí DKIM.

Klíčová slova končící na „A“ jako např ESMTPA a ESMTPSA, jsou poskytovány pro s klauzule Přijato pole záhlaví, když jsou zprávy přijímány pomocí SMTP AUTH.[8] „Klíčová slova jsou poskytována pro statistické nebo diagnostické účely.“ (RFC 3848 ); jsou kontrolovány některými klienty, např. Spamassassin.

Detaily

Stejně jako u všech rozšíření SMTP je v odpovědi EHLO inzerován SMTP AUTH spolu se seznamem podporovaných metod ověřování. Tyto metody se mohou po vydání změnit STARTTLS, což obvykle umožňuje hesla ve formátu prostého textu pouze v druhém případě. RFC 4954 poskytuje následující příklad („C:“ a „S:“ nejsou součástí protokolu, označují řádky odeslané klientem a serverem):

S: 220 smtp.example.com Server ESMTP C: EHLO client.example.com S: 250-smtp.example.com Dobrý den klient.example.comS: 250 AUTH GSSAPI DIGEST-MD5S: 250-ENHANCEDSTATUSCODESS: 250 STARTTLSC: STARTTLSS: 220 Ready to start TLS ... vyjednávání TLS pokračuje.      Další příkazy chráněné vrstvou TLS ...C: EHLO client.example.com S: 250-smtp.example.com Dobrý den klient.example.comS: 250 AUTH GSSAPI DIGEST-MD5 PLAINC: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ =S: 235 2.7.0 Ověření úspěšné

SMTP AUTH lze použít také na portu 25. Servery obvykle odmítají příkazy RCPT TO, které znamenají předávání, pokud nebyly přijaty ověřovací údaje. Specifikace doporučuje, aby servery vydávaly 530 5.7.0 Vyžaduje se ověření v reakci na většinu příkazů v případě, že je server nakonfigurován na vyžadovat ověřování a klient to ještě neudělal. Tímto způsobem by měly být konfigurovány pouze servery naslouchající na portu 587 nebo soukromé servery, nikoli Message eXchange (MX). Historická vlastnost, že SMTP není ve výchozím nastavení ověřována, však v některých případech vede k odlišnému chování s ohledem na přístupové protokoly; například při použití AUTH EXTERNAL po STARTTLS.[9]

kromě AUTH příkaz, rozšíření také poskytuje AUTH parametr do POŠTA OD příkaz, aby bylo možné odlišit autentizaci od autorizace. Tímto způsobem se odesílatel může identifikovat a přenášet několik zpráv během stejné relace. I když se ověřování nemusí lišit, po založení mohou být různé zprávy odesílány podle různých dohod, a proto vyžadují různé oprávnění. Například zprávy mohou být přenášeny jménem různých uživatelů. Použití tohoto parametru je mnohem méně populární než použití příkazu k udělení privilegií přenosu.

Při použití ověřování by se k pozdravu mělo použít EHLO Rozšířený SMTP je používán, na rozdíl od zastaralého pozdravu HELO,[10] který je stále přijímán když není použito žádné rozšíření, pro zpětnou kompatibilitu.

Text psaný velkými písmeny po AUTH příkaz je seznam typů autorizace, které server SMTP přijme.

Mezi příklady autorizačních protokolů patří:

Standardy

  • RFC 3207, Rozšíření služby SMTP pro zabezpečený SMTP přes zabezpečení transportní vrstvy, Paul Hoffman, únor 2002.
  • RFC 3848, Registrace typů přenosu ESMTP a LMTP, Chris Newman, červenec 2004.
  • RFC 6409, Odesílání zpráv pro poštu, Randall Gellens a John C. Klensin, Listopad 2011 (zastaralé RFC 4409, z roku 2006, který zase nahradil RFC 2476, z prosince 1998).
  • RFC 4422, Jednoduchá vrstva ověřování a zabezpečení (SASL), Alexey Melnikov a Kurt D. Zeilenga, červen 2006.
  • RFC 4616, Mechanismus PLAIN SASL, K. Zeilenga, ed., Srpen 2006.
  • RFC 4954, Rozšíření služby SMTP pro ověřování, Robert Siemborski a Alexey Melnikov, červenec 2007.
  • RFC 7628, Sada mechanismů jednoduchého ověřování a vrstvy zabezpečení (SASL) pro OAuth, W. Mills, T. Showalter a H. Tschofenig, srpen 2015.

jiný

Viz také

Reference

  1. ^ Příslušné RFC pro referenci jsou specifikovány v # Standardy sekce
  2. ^ Správci Indiana University (2008-04-01). „V Unixu, co je to otevřené poštovní relé?“. Univerzitní služby informačních technologií. Indiana University. Archivovány od originál dne 2007-06-17. Citováno 2008-04-07.
  3. ^ John Gardiner Myers (duben 1995). „Rozšíření služby SMTP pro ověření“. IETF. Citováno 2010-05-30.
  4. ^ Sean Turner, Lily Chen (březen 2011). „Aktualizované bezpečnostní aspekty pro MD5 Message-Digest a HMAC-MD5 Algorithms“. IETF.
  5. ^ Paul Hoffman (1. února 1998). „Povolení přenosu v SMTP: průzkum“. Konsorcium pro internetovou poštu. Citováno 2010-05-30.
  6. ^ Paul Hoffman (srpen 2002). „Povolení přenosu v SMTP: řada průzkumů“. Konsorcium pro internetovou poštu. Archivovány od originál dne 18.01.2007. Citováno 2010-05-30.
  7. ^ Randall Gellens (19. ledna 2005). „Zpráva o interoperabilitě odesílání zpráv“. IETF. Citováno 2019-07-05.
  8. ^ "Parametry pošty". IANA registr. Citováno 2011-07-23.
  9. ^ Chris Newman (30. dubna 2010). „Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL“. IETF. Citováno 2010-05-30.
  10. ^ https://tools.ietf.org/html/rfc5321; Nicméně pro kompatibilita se staršími implementacemi vyhovujícími, SMTP klienti a servery MUSÍ podporovat původní mechanismy HELO jako záložní řešení.
  11. ^ K. Murchison a M. Crispin, Mechanismus PŘIHLÁŠENÍ SASL Ze dne 28. srpna 2003, platnost uplynula. PŘIHLÁŠENÍ je popsáno jako zastaralé v Mechanismy SASL dokument, ale mechanismus se stále používá.