SMTP-autentisering

SMTP Authentication , ofta förkortat SMTP AUTH , är en förlängning av Simple Mail Transfer Protocol (SMTP) där en klient kan logga in med vilken autentiseringsmekanism som helst som stöds av servern. Den används främst av inlämningsservrar , där autentisering är obligatorisk.

Historia

SMTP, som specificerats av Jon Postel på 1970-talet, förutsåg inte att lösenord användes för att skicka e-postmeddelanden; Varje server var designmässigt ett öppet e-postrelä . Som ett resultat hade skräppost och maskar , även om det från början inte var ett problem, blivit en pest i slutet av 90-talet. Före SMTP AUTH måste en reläklient identifieras med IP-adress , vilket endast är praktiskt för e-posttjänster som tillhandahålls av samma Internetleverantör (ISP) som tillhandahåller anslutningen, eller annars med specifika hack, som POP före SMTP .

John Gardiner Myers publicerade det första utkastet till SMTP AUTH 1995, och det har successivt utvecklats och diskuterats i IETF tillsammans med e-postinlämningsprotokoll, Extended SMTP (ESMTP) och Simple Authentication and Security Layer (SASL). En äldre SASL-mekanism för ESMTP-autentisering (ESMTPA) är CRAM-MD5 , och användningar av MD5- algoritmen i HMACs (hash-baserade meddelandeautentiseringskoder) anses fortfarande vara sunda.

Internet Mail Consortium (IMC) rapporterade att 55 % av e-postservrarna var öppna reläer 1998, men mindre än 1 % 2002.

Roll i posttransportsystemet

Att använda en e-postsubmissionsagent (MSA), vanligtvis på port 587, innebär SMTP AUTH. MSA-användning stöds av de flesta program och rekommenderas, särskilt för att stödja nomadiska användare, eftersom flera nätverkshubbar antingen blockerar port 25 eller använder SMTP-proxies . MSA ansvarar för att säkerställa att meddelandekuvertet innehåller bra adresser och kan tillämpa lokala policyer för Från -huvud. Att verifiera att kuvertavsändaren (aka Return-Path ) som används för SPF och Från -adressen överensstämmer med det autentiserade användar-id:t är särskilt viktigt för domäner som signerar meddelanden med DKIM .

Nyckelord som slutar på "A" såsom ESMTPA och ESMTPSA tillhandahålls för med -satsen Mottagna rubrikfält, när meddelanden tas emot med SMTP AUTH. "Nyckelorden tillhandahålls för statistiska eller diagnostiska ändamål" ( RFC 3848); de kontrolleras av vissa kunder, t.ex. Spamassassin .

Detaljer

Som med alla SMTP-tillägg annonseras SMTP AUTH i EHLO-svaret, tillsammans med en lista över autentiseringsmetoder som stöds. Dessa metoder kan ändras efter att STARTTLS har utfärdats , vilket vanligtvis endast tillåter vanliga textlösenord i det senare fallet. RFC 4954 tillhandahåller följande exempel ("C:" och "S:" är inte en del av protokollet, de indikerar rader som skickas av klienten respektive servern): 

 
     
 S: 220 smtp.example.com ESMTP-server C: EHLO client.example.com S: 250-smtp.example.com Hej client.example.com  S: 250-AUTH GSSAPI DIGEST-MD5  S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Klar att starta TLS  ... TLS-förhandling fortsätter.  Ytterligare kommandon skyddas av TLS-skiktet ...  C: EHLO client.example.com S: 250-smtp.example.com Hej client.example.com  S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN  C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=  S: 2.7.0 Autentiseringen lyckades

SMTP AUTH kan också användas på port 25. Vanligtvis avvisar servrar RCPT TO-kommandon som innebär vidarebefordran om inte autentiseringsuppgifter har accepterats. Specifikationen rekommenderar att servrar utfärdar 530 5.7.0 Autentisering som krävs som svar på de flesta kommandon om servern är konfigurerad att kräva autentisering och klienten inte har gjort det ännu. Endast servrar som lyssnar på port 587, eller privata servrar, ska konfigureras på det sättet, inte en Message eXchange (MX). Men det historiska draget att SMTP inte autentiseras som standard resulterar i ett annat beteende med avseende på åtkomstprotokoll, i vissa fall; till exempel när du använder AUTH EXTERNAL efter STARTTLS.

Förutom AUTH -kommandot tillhandahåller tillägget också en AUTH- parameter till MAIL FROM- kommandot, för att göra det möjligt att skilja autentisering från auktorisering. På så sätt kan en avsändare identifiera sig och sända flera meddelanden under samma session. Även om autentiseringen inte behöver variera, kan olika meddelanden skickas i enlighet med olika avtal när de väl är etablerade och kräver därför olika auktorisering. Till exempel kan meddelanden vidarebefordras på uppdrag av olika användare. Användning av denna parameter är mycket mindre populär än att använda kommandot för att ge reläbehörigheter.

SMTP-autentisering är en "tillägg" i SMTP-termer, så det kräver att server och klient använder EHLO-verb för hälsning för att indikera stöd för tillägg, i motsats till den föråldrade HELO-hälsningen. För bakåtkompatibilitet kan HELO-hälsning accepteras när ingen anknytning används .

Den stora texten efter AUTH -kommandot är en lista över de typer av auktorisering som SMTP-servern accepterar.

Några exempel på auktoriseringsprotokoll inkluderar:

Standarder

  • RFC 3207 , SMTP Service Extension for Secure SMTP over Transport Layer Security, Paul Hoffman, februari 2002.
  • RFC 3848 , ESMTP och LMTP Transmission Types Registration , Chris Newman, juli 2004.
  • RFC 6409 , Message Submission for Mail , Randall Gellens och John C. Klensin , november 2011 (föråldrad RFC 4409, från 2006, som i sin tur ersatte RFC 2476, från december 1998).
  • RFC 4422 , Simple Authentication and Security Layer (SASL) , Alexey Melnikov och Kurt D. Zeilenga, juni 2006.
  • RFC 4616 , The PLAIN SASL Mechanism , K. Zeilenga, red., augusti 2006.
  • RFC 4954 , SMTP Service Extension for Authentication , Robert Siemborski och Alexey Melnikov, juli 2007.
  • RFC 7628 , En uppsättning av mekanismer för enkel autentisering och säkerhetslager (SASL) för OAuth , W. Mills, T. Showalter och H. Tschofenig, augusti 2015.

Övrig

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=SMTP_Authentication&oldid=1143222168 "