{"id":91951,"date":"2020-08-20T19:42:11","date_gmt":"2020-08-20T17:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts"},"modified":"2020-08-20T19:42:11","modified_gmt":"2020-08-20T17:42:11","slug":"pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts","title":{"rendered":"Mail.ru begynder i testfase at anvende MTA-STS-politikker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Mail.ru begynder i testfase at anvende MTA-STS-politikker\" src=\"\/wp-content\/uploads\/2020\/08\/1f0b7542aedb372c06c2077ea987dd36.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKort sagt er MTA-STS en metode til at beskytte emails mod interception (dvs. mand-i-midt angreb aka MitM) under transmission mellem mailservere. Det adresserer delvist eksisterende arkitektoniske problemer i emailprotokoller og er beskrevet i den relativt nye standard RFC 8461. Mail.ru er den f\u00f8rste store mailtjeneste i Rusland, der implementerer denne standard. Der gives en mere detaljeret forklaring l\u00e6ngere nede.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Hvad problem l\u00f8ser MTA-STS?<\/h1>\n<p>\nHistorisk set har emailprotokoller (SMTP, POP3, IMAP) sendt informationer i klar tekst, hvilket g\u00f8r det muligt at opfange dem, for eksempel ved adgang til kommunikationskanalen.<\/p>\n<p>Hvordan ser mekanismen for levering af en email fra en bruger til en anden ud:<\/p>\n<p><img decoding=\"async\" alt=\"Mail.ru begynder i testfase at anvende MTA-STS-politikker\" src=\"\/wp-content\/uploads\/2020\/08\/5b0d4749298d7644220a6322912d8716.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHistorisk set har MitM angreb v\u00e6ret mulige alle steder, hvor post passerer.<\/p>\n<p>RFC 8314 standarden kr\u00e6ver obligatorisk brug af TLS mellem brugerens mailprogram (MUA) og mailserveren. Hvis din server og de anvendte mailapplikationer overholder RFC 8314, s\u00e5 har du (i h\u00f8j grad) elimineret muligheden for Man-in-the-Middle angreb mellem brugeren og mailserverne.<\/p>\n<p>Overholdelse af anerkendte praksisser (standardiserede RFC 8314) eliminerer angreb t\u00e6t p\u00e5 brugeren:<\/p>\n<p><img decoding=\"async\" alt=\"Mail.ru begynder i testfase at anvende MTA-STS-politikker\" src=\"\/wp-content\/uploads\/2020\/08\/7a45c95793ec958c46f63898db39c1fc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMail.ru's mailservere overholdt RFC 8314 allerede f\u00f8r standardens vedtagelse; faktisk bekr\u00e6ftede den blot allerede vedtagne praksisser, og vi beh\u00f8vede ikke at foretage yderligere indstillinger. Men hvis din mailserver stadig tillader brugere at kommunikere via usikre protokoller, b\u00f8r du helt sikkert implementere anbefalingerne fra denne standard, da det sandsynligvis betyder, at mindst en del af dine brugere benytter email uden kryptering, selvom du underst\u00f8tter det.<\/p>\n<p>Mailklienten arbejder altid med den samme mailserver fra den samme organisation. Det er muligt at tvinge alle brugere til at oprette forbindelse p\u00e5 en sikker m\u00e5de, hvorefter det teknisk bliver umuligt at etablere usikre forbindelser (som kr\u00e6vet af RFC 8314). Dette kan v\u00e6re komplekst, men det er muligt. Med trafik mellem mailserverne er det endnu mere kompliceret. Serverne tilh\u00f8rer forskellige organisationer og bruges ofte i en 's\u00e6t og glem'-tilstand, hvilket g\u00f8r \u00f8jeblikkelig overgang til en sikker protokol umulig uden at bryde forbindelsen. I SMTP har der l\u00e6nge v\u00e6ret en udvidelse kaldet STARTTLS, der g\u00f8r det muligt for servere, der underst\u00f8tter kryptering, at skifte til TLS. Men en angriber, der er i stand til at p\u00e5virke trafikken, kan 'fjerne' information om underst\u00f8ttelsen af denne kommando og tvinge serverne til at kommunikere via den almindelige tekstprotokol (s\u00e5kaldt downgrade attack). Af samme grund tjekkes der normalt ikke certifikatoverensstemmelse for STARTTLS (et ikke-betroet certifikat kan beskytte mod passive angreb, og det er ikke v\u00e6rre end at sende en e-mail i klartekst). Derfor beskytter STARTTLS kun mod passiv aflytning.<\/p>\n<p>MTA-STS delvist l\u00f8ser problemet med aflytning af e-mails mellem mailserverne, n\u00e5r en angriber har mulighed for aktivt at p\u00e5virke trafikken. Hvis modtagerdommens publikerer en MTA-STS-politik, og afsenderserveren underst\u00f8tter MTA-STS, vil den sende e-mailen kun via en TLS-forbindelse, kun til servere specificeret i politikken, og kun med validering af servercertifikatet.<\/p>\n<p>Hvorfor kun delvist? MTA-STS fungerer kun hvis begge parter har taget sig af at implementere denne standard, og MTA-STS beskytter ikke mod scenarier, hvor en angriber har mulighed for at f\u00e5 et gyldigt dom\u00e6necertifikat fra en af de offentlige CA'er.<\/p>\n<h1>Hvordan fungerer MTA-STS<\/h1>\n<p>\n<b>Modtageren<\/b><\/p>\n<ol>\n<li>Konfigurerer underst\u00f8ttelse af STARTTLS med et gyldigt certifikat p\u00e5 mailserveren.\u00a0<\/li>\n<li>Offentligg\u00f8r MTA-STS-politikken via HTTPS; der anvendes et specielt dom\u00e6ne mta-sts og en speciel well-known sti, for eksempel <code>https:\/\/mta-sts.mail.ru\/.well-known\/mta-sts.txt<\/code>. Politikken indeholder en liste over mailservere (mx), der har ret til at modtage mail for dette dom\u00e6ne.<\/li>\n<li>Publicerer en speciel TXT-post _mta-sts i DNS med politikversion. N\u00e5r politikken \u00e6ndres, skal denne post opdateres (det signalerer til afsenderen, at den skal anmode om politikken igen). For eksempel, <code>_mta-sts.mail.ru. TXT \"v=STSv1; id=20200303T120000;\"<\/code><\/li>\n<\/ol>\n<p>\n<b>Afsender<\/b><\/p>\n<p>Afsenderen anmoder om DNS-posten _mta-sts, og hvis den findes, laver den en politikforesp\u00f8rgsel via HTTPS (med kontrol af certifikatet). Den modtagne politik caches (i tilf\u00e6lde af, at en angriber blokerer adgangen til den eller \u00e6ndrer DNS-posten).<\/p>\n<p>Ved afsendelse af e-mails kontrolleres det, at:<\/p>\n<ul>\n<li>serveren, som e-mailen leveres til, er i politikken;<\/li>\n<li>serveren modtager e-mail med brug af TLS (STARTTLS) og har et gyldigt certifikat.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Fordele ved MTA-STS<\/h1>\n<p>\nMTA-STS bruger teknologier, der allerede er implementeret i de fleste organisationer (SMTP+STARTTLS, HTTPS, DNS). Der kr\u00e6ves ikke s\u00e6rlig softwareunderst\u00f8ttelse af standarden p\u00e5 modtagerens side.<\/p>\n<h1>Ulemper ved MTA-STS<\/h1>\n<p>\nDet er n\u00f8dvendigt at holde \u00f8je med gyldigheden af certifikaterne for web- og mailservere, overensstemmelse af navne, samt rettidig opdatering. Problemer med certifikatet vil f\u00f8re til, at e-mailen ikke kan leveres.<\/p>\n<p>P\u00e5 afsenderens side kr\u00e6ves en MTA, der underst\u00f8tter MTA-STS-politikker; i \u00f8jeblikket underst\u00f8ttes MTA-STS ikke 'out of the box' i MTA.<\/p>\n<p>MTA-STS bruger en liste over betroede rod-CA'er.<\/p>\n<p>MTA-STS beskytter ikke mod angreb, hvor en angriber bruger et gyldigt certifikat. I de fleste tilf\u00e6lde involverer MitM t\u00e6t p\u00e5 serveren muligheden for at udstede et certifikat. S\u00e5dan et angreb kan opdages takket v\u00e6re Certificate Transparency. S\u00e5 i det hele taget mitigere MTA-STS, men fjerner ikke helt muligheden for at intercept trafik.<\/p>\n<p>De to sidste punkter g\u00f8r MTA-STS mindre sikker end den konkurrerende standard DANE for SMTP (RFC 7672), men mere teknisk p\u00e5lidelig, dvs. for MTA-STS er sandsynligheden for, at en e-mail ikke leveres p\u00e5 grund af tekniske problemer for\u00e5rsaget af standardens implementering lav.<\/p>\n<h4>Den konkurrerende standard er DANE<\/h4>\n<p>\nDANE bruger DNSSEC til at offentligg\u00f8re oplysninger om certifikater og kr\u00e6ver ikke tillid til eksterne certifikatmyndigheder, hvilket er langt sikrere. Men brugen af DNSSEC f\u00f8rer markant oftere til tekniske fejl, hvis man ser p\u00e5 statistikker fra flere \u00e5rs anvendelse (selv om der generelt er positive tendenser i p\u00e5lideligheden af DNSSEC og dens tekniske support). For at implementere DANE i SMTP p\u00e5 modtagerens side er det n\u00f8dvendigt, at DNSSEC er aktiveret for DNS-zonen, og korrekt underst\u00f8ttelse af NSEC\/NSEC3 er v\u00e6sentlig, da der er systematiske problemer med dette i DNSSEC.<\/p>\n<p>Hvis DNSSEC er konfigureret forkert, kan det f\u00f8re til problemer med maillevering, hvis afsenderen underst\u00f8tter DANE, selvom modtageren ikke ved noget om det. Derfor, selvom DANE er en \u00e6ldre og mere sikker standard og allerede er underst\u00f8ttet i visse serverprogrammer p\u00e5 afsenderens side, er det faktiske udbredelse stadig meget begr\u00e6nset. Mange organisationer er ikke parate til at implementere det p\u00e5 grund af behovet for at realisere DNSSEC, hvilket har bremset implementeringen af DANE gennem de \u00e5r, standarden har eksisteret.<\/p>\n<p>DANE og MTA-STS er ikke i konflikt med hinanden og kan anvendes sammen.<\/p>\n<h1>Hvordan er underst\u00f8ttelsen af MTA-STS i Mail.ru?<\/h1>\n<p>\nMail.ru har l\u00e6nge offentliggjort MTA-STS-politik for alle st\u00f8rre dom\u00e6ner. Vi arbejder nu p\u00e5 at implementere klientdelen af standarden. P\u00e5 tidspunktet for denne artikels skrivning anvendes politikker i en ikke-blokerende tilstand (hvis leveringen blokeres af politikken, vil mailen blive leveret via en 'backup'-server uden anvendelse af politikker), og derefter vil den blokerende tilstand blive p\u00e5tvunget for en lille del af den udsendte SMTP-trafik, og gradvist vil 100% af trafikken st\u00f8tte anvendelsen af politikker.<\/p>\n<h1>Hvem andre underst\u00f8tter standarden?<\/h1>\n<p>\nI \u00f8jeblikket offentligg\u00f8r cirka 0,05% af aktive dom\u00e6ner MTA-STS-politikker, men de beskytter allerede et stort volumen af mailtrafik, da store akt\u00f8rer som Google, Comcast og delvist Verizon (AOL, Yahoo) underst\u00f8tter standarden. Mange andre mailtjenester har erkl\u00e6ret, at underst\u00f8ttelsen af standarden vil blive implementeret i den n\u00e6rmeste fremtid.<\/p>\n<h1>Hvordan vil dette p\u00e5virke mig?<\/h1>\n<p>\nIkke, hvis dit dom\u00e6ne ikke offentligg\u00f8r en MTA-STS-politik. Hvis du offentligg\u00f8r en politik, vil e-mails til brugere af din mailserver v\u00e6re bedre beskyttet mod aflytning.<\/p>\n<h1>Hvordan implementerer jeg MTA-STS?<\/h1>\n<p>\n<b>Underst\u00f8ttelse af MTA-STS p\u00e5 modtagerens side<\/b><\/p>\n<p>Det er tilstr\u00e6kkeligt at offentligg\u00f8re en politik via HTTPS og DNS-poster, konfigurere et gyldigt certifikat fra en af de betroede CA'er (for eksempel Let's Encrypt) til STARTTLS i MTA (STARTTLS underst\u00f8ttes i alle moderne MTA'er), speciel support fra MTA er ikke n\u00f8dvendig.<\/p>\n<p>I trin ser det s\u00e5ledes ud:<\/p>\n<ol>\n<li>Konfigurer STARTTLS i den MTA, du bruger (postfix, exim, sendmail, Microsoft Exchange osv.).<\/li>\n<li>S\u00f8rg for, at et gyldigt certifikat anvendes (udstedt af en betroet CA, ikke udl\u00f8bet, certifikatets emne svarer til MX-posten, hvor mailen til dit dom\u00e6ne leveres).<\/li>\n<li>Konfigurer TLS-RPT-posten, hvor rapporter om politikl\u00f8sning vil blive sendt (af tjenester, der underst\u00f8tter afsendelse af TLS-rapporter). Eksempel p\u00e5 optegnelse (for dom\u00e6net example.com):\n<pre><code class=\"plaintext\">smtp._tls.example.com. 300 IN TXT \"v=TLSRPTv1;rua=mailto:tlsrpt@example.com\"<\/code><\/pre>\n<p>\nDenne post instruerer mailafsendere til at sende statistiske rapporter om brugen af TLS i SMTP til adressen <code>tlsrpt@exmple.com<\/code>.<\/p>\n<p>Hold \u00f8je med rapporterne i et par dage, og s\u00f8rg for, at der ikke er fejl.<\/li>\n<li>Offentligg\u00f8r MTA-STS-politikken via HTTPS. Politikken offentligg\u00f8res som en tekstfil med CRLF linjeskift.\n<pre><code class=\"plaintext\">https:\/\/mta-sts.example.com\/.well-known\/mta-sts.txt\n<\/code><\/pre>\n<p>\nEksempel p\u00e5 politik:<\/p>\n<pre><code class=\"plaintext\">version: STSv1\nmode: enforce\nmx: mxs.mail.ru\nmx: emx.mail.ru\nmx: mx2.corp.mail.ru\nmax_age: 86400\n<\/code><\/pre>\n<p>\nFeltet version indeholder den version af politikken (nu er det <code>STSv1<\/code>), mode angiver politikforl\u00f8bsmodus, testing - testmodus (politikken anvendes ikke), enforce - 'produktions' modus. Offentligg\u00f8r f\u00f8rst politikken med mode: testing, hvis der ikke opst\u00e5r problemer med politikken i testmodus, kan du efter et stykke tid skifte til mode: enforce.<\/p>\n<p>I mx angives en liste over alle mailservere, der kan modtage mails til dit dom\u00e6ne (hver server skal have et certifikat konfigureret, der svarer til navnet angivet i mx). Max_age angiver cachetiden for politikken (en gang gemt, vil politikken anvendes, selvom en angriber blokerer dens levering eller \u00f8del\u00e6gger DNS-poster i cachetiden, signaleres behovet for at anmode om politikken igen ved at \u00e6ndre mta-sts DNS-posten).<\/li>\n<li>Offentligg\u00f8r en DNS TXT-post:\u00a0\n<pre><code class=\"plaintext\">_mta-sts.example.com. TXT \u201cv=STS1; id=someid;\u201d\n<\/code><\/pre>\n<p>\nI felt id kan bruges en vilk\u00e5rlig identifikator (f.eks. et tidsstempel), n\u00e5r politikken \u00e6ndres, skal den \u00e6ndres, s\u00e5 afsenderne kan forst\u00e5, at de skal anmode om at genindl\u00e6se den cachede politik (hvis identifikatoren er forskellig fra den cachede).<\/li>\n<\/ol>\n<p>\n<b>Underst\u00f8ttelse af MTA-STS p\u00e5 afsenderens side<\/b><\/p>\n<p>Det st\u00e5r ikke s\u00e5 godt til endnu, da standarden er ny.<\/p>\n<ul>\n<li>Exim - der er ingen indbygget support, der findes et tredjeparts script <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Bobberty\/MTASTS-EXIM-PERL\">https:\/\/github.com\/Bobberty\/MTASTS-EXIM-PERL<\/a><\/noindex>\u00a0<\/li>\n<li>Postfix - der er ingen indbygget support, der findes et tredjeparts script, som er beskrevet i detaljer p\u00e5 Habr\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/424961\/\">https:\/\/habr.com\/en\/post\/424961\/<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<h1>Som en efterord om 'mandatory TLS'<\/h1>\n<p>\nFor nylig har regulativerne begyndt at fokusere p\u00e5 sikkerheden af e-mails (og det er godt). For eksempel er DMARC obligatorisk for alle statslige institutioner i USA og bliver oftere kr\u00e6vet i finanssektoren, i regulerede omr\u00e5der n\u00e5r standarden n\u00e6sten 90%. I \u00f8jeblikket kr\u00e6ver nogle regulativer implementering af 'mandatory TLS' med specifikke dom\u00e6ner, men mekanismen til at sikre 'mandatory TLS' er ikke defineret, og i praksis bliver denne indstilling ofte implementeret p\u00e5 en m\u00e5de, der ikke engang mindsker risikoen mod reelle angreb, som allerede er forudset i s\u00e5danne mekanismer som DANE eller MTA-STS.<\/p>\n<p>Hvis regulat\u00f8ren kr\u00e6ver implementering af 'mandatory TLS' med specifikke dom\u00e6ner, anbefaler vi at overveje MTA-STS eller dens delvise analog som den mest passende mekanisme, det fjerner behovet for at lave sikre indstillinger for hvert enkelt dom\u00e6ne. Hvis du har vanskeligheder med implementeringen af klientdelen af MTA-STS (indtil protokol ikke f\u00e5r bred st\u00f8tte, vil de sandsynligvis eksistere), kan denne tilgang anbefales:<\/p>\n<ol>\n<li>Publicer MTA-STS politikken og\/eller DANE poster (DANE giver mening at tilf\u00f8je kun hvis DNSSEC allerede er aktiveret for dit dom\u00e6ne, og MTA-STS i hvert fald), det vil beskytte trafikken mod din side og fritage dig for at skulle bede andre e-mail tjenester om at indstille mandatory TLS for dit dom\u00e6ne, hvis e-mail tjenesten allerede underst\u00f8tter MTA-STS og\/eller DANE.<\/li>\n<li>For large email services, implement an \"equivalent\" of MTA-STS through separate transport settings for each domain, which will record the MX used for mail relaying and require mandatory TLS certificate verification. If the domains already publish an MTA-STS policy, this can likely be done without pain. Enabling mandatory TLS for a domain without fixing the relay and verifying the certificate is ineffective from a security standpoint and adds nothing to the existing STARTTLS mechanisms.<\/li>\n<\/ol>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/515746\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0415\u0441\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e, \u0442\u043e MTA-STS \u2014 \u044d\u0442\u043e \u0441\u043f\u043e\u0441\u043e\u0431 \u0434\u043e\u043f\u043e\u043b\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0438\u0441\u044c\u043c\u0430 \u043e\u0442 \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u0430 (\u0442.\u0435. \u0430\u0442\u0430\u043a \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a-\u0432-\u0441\u0435\u0440\u0435\u0434\u0438\u043d\u0435 aka MitM) \u043f\u0440\u0438 \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0435 \u043c\u0435\u0436\u0434\u0443 \u043f\u043e\u0447\u0442\u043e\u0432\u044b\u043c\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c\u0438. \u041e\u043d \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u0440\u0435\u0448\u0430\u0435\u0442 \u0443\u043d\u0430\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043d\u044b\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b \u0438 \u043e\u043f\u0438\u0441\u0430\u043d \u0432 \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u0432\u0435\u0436\u0435\u043c \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u0435 RFC 8461. \u041f\u043e\u0447\u0442\u0430 Mail.ru \u2014 \u043f\u0435\u0440\u0432\u0430\u044f \u043a\u0440\u0443\u043f\u043d\u0430\u044f \u043f\u043e\u0447\u0442\u043e\u0432\u0430\u044f \u0441\u043b\u0443\u0436\u0431\u0430 \u0432 \u0420\u0443\u043d\u0435\u0442\u0435, \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u044e\u0449\u0430\u044f \u0434\u0430\u043d\u043d\u044b\u0439 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442. \u0410 \u0431\u043e\u043b\u0435\u0435 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91952,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91951","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0415\u0441\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e, \u0442\u043e.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u043e\u0447\u0442\u0430 Mail.ru \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442 \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u043c \u0440\u0435\u0436\u0438\u043c\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0442\u044c \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 MTA-STS | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0415\u0441\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e, \u0442\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-20T17:42:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-20T17:42:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Mail.ru starts to test MTA-STS policies | ProHoster","description":"In short,","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e\u0447\u0442\u0430 Mail.ru \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442 \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u043c \u0440\u0435\u0436\u0438\u043c\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0442\u044c \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 MTA-STS | ProHoster","og:description":"\u0415\u0441\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e, \u0442\u043e.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pochta-mail-ru-nachinaet-v-testovom-rezhime-primenyat-politiki-mta-sts","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-20T17:42:11+00:00","article:modified_time":"2020-08-20T17:42:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91951","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:18:26","updated":"2022-09-27 15:16:28","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/91951","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=91951"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/91951\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/91952"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=91951"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=91951"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=91951"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}