SMTP AUTH
SMTP AUTH (SMTP Autentizace) je rozšíření protokolu Simple Mail Transfer Protocol (SMTP), které umožňuje přihlášení klient pomocí libovolného autentizačního mechanismu podporovaného serverem. Využívají jej především servery v roli Mail submission agent, kde je autentizace povinná.[1]
Historie
editovatProtokol SMTP, jak jej definoval Jon Postel v 70. letech 20. století, neumožňoval použití hesla pro odesílání e-mailových zpráv; každý server byl z podstaty věci otevřeným přenašečem elektronické pošty. Kvůli tomu se spam a počítačoví červi, které zpočátku nepředstavovaly problém, koncem 90. let 20. století staly pohromou.[2] Před nasazením SMTP AUTH se relay klient mohl identifikovat pouze IP adresou, což postačuje pouze pro e-mailové služby poskytované stejným poskytovatelem internetového připojení (ISP), který dodává připojení, nebo pomocí jiných hacků, např. POP před SMTP.
První pracovní verzi rozšíření SMTP AUTH publikoval John Gardiner Myers v roce 1995;[3] rozšíření bylo postupně vyvíjeno a diskutováno v IETF spolu s protokolem pro odesílání pošty, rozšířeným protokolem SMTP (ESMTP) a protokolem Simple Authentication and Security Layer (SASL). Starším mechanismem SASL pro ESMTP autentizaci (ESMTPA) je CRAM-MD5 a použití algoritmu Message-Digest algorithm v HMAC (hash-based message authentication codes) je stále považováno za vyhovující.[4]
Internet Mail Consortium (IMC) uvedlo, že v roce 1998 bylo 55 % poštovních serverů otevřenými relé,[5] ale v roce 2002 jich bylo méně než 1 %.[6]
Použití v systému dopravy elektronické pošty
editovatPoužití Mail submission agenta (MSA), obvykle na portu 587, implikuje SMTP AUTH. Použití MSA je podporováno většinou softwaru,[7] a doporučuje se zvláště pro podporu často se přesunujících uživatelů, protože některé síťové huby buď blokují port 25 anebo používají SMTP proxy. MSA odpovídá za to, že obálka zprávy bude obsahovat správné adresy, a může vynucovat lokální pravidla pro hlavičku From. Ověření, že odesilatel obálky (neboli Return-Path) použitý pro SPF a adresa From souhlasí s autentizovanou identifikací uživatele, je důležité zejména pro domény, které podepisují zprávy pomocí DKIM.
Pokud jsou zprávy přijímány pomocí SMTP AUTH, jsou pro with část hlaviček Received k dispozici klíčová slova zakončená písmenem „A“ např. ESMTPA a ESMTPSA.[8] „Pro statistické nebo diagnostické účely jsou uváděna klíčová slova“ (RFC 3848), která jsou kontrolována některými klienty, například Spamassassinem.
Detaily
editovatJako u všech SMTP rozšíření je SMTP AUTH oznamováno v odezvě EHLO, spolu se seznamem podporovaných autentizačních metod. Tyto metody se mohou změnit po vyslání STARTTLS, kdy typicky bude dovoleno i použití nešifrovaných hesel. RFC 4954 poskytuje následující příklad (úvodní „C:“ a „S:“ pouze indikují, které řádky posílá klient a které server, a nejsou součástí protokolu):
S: 220 smtp.prijemce.com ESMTP Server
C: EHLO klient.odesilatel.com
S: 250-smtp.prijemce.com Hello klient.odesilatel.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... probíhá TLS vyjednávání.
Další příkazy jsou již chráněné TLS vrstvou ...
C: EHLO klient.odesilatel.com
S: 250-smtp.prijemce.com Hello klient.odesilatel.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
S: 235 2.7.0 Autentication successful
SMTP AUTH může být použito i na portu 25. Servery obvykle odmítnou příkaz RCPT TO, které znamená předávání (anglicky relaying), pokud nebyly přijaty autentizační údaje. Specifikace doporučuje, aby v případě, kdy je server zkonfigurovaný, aby vyžadoval autentizaci, a klient ji ještě neprovedl, server na většinu příkazů odpovídal 530 5.7.0 Authentication required. Takto by měly být nakonfigurovány pouze servery naslouchající na portu 587 nebo soukromé servery, nikoliv servery uvedené jako MX. Historická vlastnost, že ve výchozím nastavení SMTP nepoužívá autentizaci, vede v některých případech k tomu, že chování závisí na přístupovém protokolu; například když se použije AUTH EXTERNAL po STARTTLS.[9]
Rozšíření kromě příkazu AUTH definuje také parametr AUTH příkazu MAIL FROM, které umožňuje rozlišit autentizaci od autorizace. Díky tomu se odesilatel může jednou identifikovat a předat několik zpráv během jedné relace. Zatímco jednou provedená autentizace se nemusí opakovat, různé zprávy mohou být posílány podle různých dohod a proto vyžadují různé autorizace. Zprávy mohou být například předávány jménem různých uživatelů. Tento parametru se používá mnohem méně než příkaz pro udělení oprávnění k předávání pošty.
SMTP autentizace je z hlediska SMTP „rozšíření“, takže vyžaduje, aby klient v úvodním vyjednávání místo příkazu HELO používal příkaz EHLO indikující, že podporuje rozšíření.[10] Pro zpětnou kompatibilitu může být přijat příkaz HELO, pokud se nepoužívá žádné rozšíření.
Slova uvedená velkými písmeny za příkazem AUTH, je seznam typů autorizace, které SMTP server přijímá.
K autorizačním protokolům patří:
- PLAIN (používá kódování Base64)
- LOGIN (používá kódování Base64)[11] (nahrazeno PLAIN)
- GSSAPI (Generic Security Services Application Program Interface)
- DIGEST-MD5 (Digest access authentication)
- MD5
- CRAM-MD5
- OAUTH10A (OAuth 1.0a HMAC-SHA1 tokeny definované v RFC 5849)
- OAUTHBEARER (OAuth 2.0 přenosové tokeny definované v RFC 6750)
- XOAUTH2 [12]
Standardy
editovat- HOFFMAN, Paul. RFC3207: SMTP Service Extension for Secure SMTP over Transport Layer Security [online]. Únor 2002.
- NEWMAN, Chris. RFC3848: ESMTP and LMTP Transmission Types Registration [online]. Červenec 2004.
- GELLENS, Randall; KLENSIN, John C. RFC6409: Message Submission for Mail [online]. Listopad 2011. Nahrazuje zastaralé RFC 4409 z roku 2006, které naopak nahrazuje RFC 2476 z prosince 1998.
- MELNIKOV, Alexey; ZEILENGA, Kurt D. RFC4422: Simple Authentication and Security Layer (SASL) [online]. Červen 2006.
- ZEILENGA (ED.), K. RFC4616: The PLAIN SASL Mechanism [online]. Srpen 2006.
- SIEMBORSKI, Robert; MELNIKOV, Alexey. RFC4954: SMTP Service Extension for Authentication [online]. Červenec 2007.
- MILLS, W.; SHOWALTER, T.; TSCHOFENIG, H. RFC7628: A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth [online]. Srpen 2015.
Jiné
editovat- HOFFMANN, Erwin. SMTP Authentication [Tutorial] [online]. 2017-01-10. Dostupné online.
Odkazy
editovatReference
editovatV tomto článku byl použit překlad textu z článku SMTP Authentication na anglické Wikipedii.
- ↑ Relevantní RFC jsou uvedeny v části #Standardy
- ↑ THE TRUSTEES OF INDIANA UNIVERSITY. In Unix, what is an open mail relay? [online]. Indiana University, 2008-04-01 [cit. 2008-04-07]. Dostupné v archivu pořízeném dne 2007-06-17.
- ↑ John Gardiner Myers. SMTP Service Extension for Authentication [online]. IETF, April 1995 [cit. 2010-05-30]. Dostupné online.
- ↑ Sean Turner, Lily Chen. RFC6151: Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms [online]. IETF, March 2011.
- ↑ Paul Hoffman. Allowing Relaying in SMTP: A Survey [online]. Internet Mail Consortium, 1998-02-01 [cit. 2010-05-30]. Dostupné v archivu pořízeném dne 2016-03-05.
- ↑ Paul Hoffman. Allowing Relaying in SMTP: A Series of Surveys [online]. Internet Mail Consortium, August 2002 [cit. 2010-05-30]. Dostupné v archivu pořízeném dne 2007-01-18.
- ↑ Randall Gellens. Message Submission Interoperability Report [online]. IETF, 2005-01-19 [cit. 2019-07-05]. Dostupné online.
- ↑ Mail parameters [online]. [cit. 2011-07-23]. Dostupné online.
- ↑ Chris Newman. Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL [online]. IETF, 30 Apr 2010 [cit. 2010-05-30]. Dostupné online.
- ↑ RFC 5321: Simple Mail Transfer Protocol [online]. Kapitola 2.2.1. Pro kompatibilitu se staršími implementacemi MUSÍ SMTP klienti a servery podporovat původní HELO mechanismus jako zálohu..
- ↑ K. Murchison and M. Crispin, The LOGIN SASL Mechanism, 28. srpna 2003, expired draft. LOGIN je v dokumentu SASL Mechanisms popisován jako zastaralý, ale mechanismus se stále používá.
- ↑ Gmail's XOAuth2 SASL protocol