 Now for the next talk we will be learning about the state of email security in 2015 Which is an important topic as you all know email is a thing that people use Also we come to the translation of this for trucks Neither snow nor rain nor men in the middle the state of email security in 2015 and The lecture will start right away. The Herald tells us a little bit about it and we will click on it with the translation Thank you for the introduction. It's nice to be here again I would like to look at the first line today as to how email is protected So if you think of email security, then it's mostly about PGP or S-Mime But the reality is unfortunately that only a very small amount of emails with GPG and S-Mime is shut down And what is now with all the emails that do not use GPG And the thing is The email providers have some protocols Included to ensure that these emails are somehow secured and I would like Over the state of the art to speak and which attack surfaces so access areas there is the Inhalte this contract is based on a collaboration with the University of Michigan and Google and And it's just also about internet Wide scanning from email transfer When I transfer my email Transition security, what do I mean with that? No, and we are just So we start at the beginning how does email actually work? So if you send an email Then you use the SMTP server of your company or the providers and And we call the whole thing a SMTP service submission And the server takes care of delivering it and The SMTP server makes a mx leg up and a dns look up and And he then gets the name of an email service that is supposed to receive it and an IP address and The server then takes care of the transmission of the server and this Server keeps the email and then delivers it with pop 3 or a map or with a web interface on the ad user And user TLS wie ähnlich wie sie htdps für htdp htdp verwenden And Was ich jetzt fokussieren will ist ich möchte mich darauf fokussieren was in der Mitte passiert das ist der Teil der über das internet läuft wie wird ihm email übertragen zwischen meine organisation mein provider zu dem anderen zu einer anderen organisation und und es gibt halt keine sicherheit in dem protokoll es wird alles im klartext geschickt und man vertraut der email halt vom origine vom ursprünglichen sender Und das ist halt nicht das was wir eigentlich wollen für email weil sehr viele sehr vertrauenswürdige Kommunikation über email ablaufen und und es gibt halt diese features die das ganze deutlich sicherer machen allerdings Niemand von euch hat diese technologien wahrscheinlich jemals gesehen und das ist alles unsichtbar für den end nutzer und ihr wisst halt nicht ob eure email vernünftig verschlüsselt ist oder nicht Ihr wisst nicht ob eure universität die ganzen email vernünftig verschlüsselt überträgt und wie funktioniert das ganze in der praxis das erste protokoll ist ist wahrscheinlich das Bekannteste ist start tls und start tls ist halt tls für smtp und es ermöglicht es die übertragung der email verschlüsselt durchzuführen Das protokoll ist ziemlich einfach man fängt halt eine normale tlcp Sitzung an man macht ein handshake man send ein hello und der server sagt dann halt start tls oder der klein sagt das und dann Und und dann sagt der server sagt okay, ja ich kann es Tls wir machen jetzt tls verschlüsselung Und dann wird es halt alles verhandelt und dann kannst du halt kann man halt die email raus senden Allerdings ist das das ist etwas anders als bei http the Art and Weise wie wir tls mit smtp verwenden ist halt opportunistisch also nur wenn es verfügbar ist und das rfc sagt tatsächlich Es ist nicht verpflichtend dass tls verwendet wird wenn tls nicht verwendet wird oder nicht unterstützt wird dann ist die einzelne alternative dass man das ganze im klartext raus endet und And Also Anmerkung das übersetzt es entspricht jetzt über zertifikate aber das ganze geht jetzt gerade ein bisschen schnell mich steigt gleich wieder ein und am ende des tages niemand validiert irgendwelche zertifikate weil Weil man sich halt nicht darauf verlässt Und niemand ist sie am ende weiß am ende des tages am ende Sind wir nicht in einer position dass wir also das Verlangen können weil so viele server das noch nicht unterstützen dieses start tls Eigentlich ist es noch komplizierter weil selbst wenn alle start tls unterstützen gibt es immer noch eine weitere schicht von ja eine weitere abstattung schicht in smtp nämlich anders als bei https wo man dann gleich Das zeug zurück erhält wenn ich ein email an gmail.com geht schau ich mir den mx record an und dann komme ich bekomme ich eine liste von namen Also zum beispiel smtp.gmail.com und dann mache ich einen zweiten lookup für die ip adresse von smtp.gmail.com und das ist dann da wo ich meine email hinschicke Also ja wo tut man jetzt das zertifikat hin man kann es auf den eigentlichen smtp server tun oder Eigentlich die domain gmail.com Also ja der name des servers zu schützen nützt uns ja einfach eigentlich nichts also wenn man jetzt der mended middle ist und das angreifen will dann Gehe man davon aus dem dass ja der dns server ein e anlügt und man im falsche name gibt und natürlich wenn ich dann einen Eigen smtp server habe dann kann ich mir ein gültiges zertifikat darauf ausstellen also Ja also man muss natürlich im gmail.com tatsächlich selbst schützen damit ich weiß dass ich mich dahin verbinde und das soll der smtp server sein aber die vielen großen anbieter verschieben tatsächlich smtp server also das hat der anteil also 25 prozent Haben einen separaten mail server also wenn es gmail ein server braucht dass Für den server passt wo man die mail hinschickt dann muss man natürlich auch Ein zertifikat haben das haben das 16 prozent der domains im internet parts also ist Nicht wirklich machbar Das umzusetzen Also nicht sofort klar wie man das macht es gibt keine wirklich irgendwie jetzt zwischenlösung Dass wir voraussetzen können aus der tls verwenden schauen wir uns die daten an Das ist der anteil der nachrichten die rein und raus geht bei gmail welche start tls verwendet Also wir haben da großen fortschritt gemacht in den letzten paar jahren im letzten jahr Also etwa 80 prozent der nachrichten die rausgehen Verwendet start tls und ungefähr 60 prozent die reinkommen benutzen start tls bei der gleichen zeit Also das war aber weil andere provider ihr tls Verwendung umgestellt haben zum Beispiel hier anfangs 2014 haben jahu und hotmail start tls zu verwenden begonnen Und wenn man jetzt das hier beiseite lässt dann ist nicht viel passiert Also wir machen nämlich keine großartigen forsch mit fortschritt ist nur eine kleine Handvoll anbieter die umgestellt haben Also das ist ja noch eine spannende kurve es geht da hoch und runter und das sind wochentage im vergleich zu wochenenden Also bei den emails die bei gmail ankommen sind etwa 10 prozent mehr verschlüsselte emails an an wochenen im vergleich zu während dem wochentage wir vermuten am wochenende benutzen halt leutere privaten accounts und während unter der woche während die emails die aus dem büro verschickt werden sind weniger oft verschlüsselt Es ist ein sehr empfindliches ökosystem man sieht da diesen großen sprung bei von minus 20 prozent und Als da die pudel vulnerability veröffentlicht wurde weil scheinbar leute panik hatten und einfach The less abgestalt abgeschilded hatten und ja es ist natürlich nicht was wir wollen es ist ein ziemliches haus nach bei großen anbietern heute Benützmann sehr Exotische cyphers also das sind die großen email anbieter im email Man sieht hier wird immer noch rc4 verwendet facebook hat zum beispiel ein zertifikat das ungültig ist Also es zwar ein gültiges zertifikat das passt aber nicht zu ihrem mailserver und ja das sind die zehn größten email versender der welt Haben das heute morgen noch mal angeschaut also ja und er stützt immer noch rc4 Natürlich Hinter den top ten sieht es aber auch nicht viel besser aus also von der top einer million domains Unterstützen etwa 80 prozent stateles 34 prozent haben zertifikat dass dem mx server zum eng server passt aber nur 0,6 prozent haben zertifikat das wirklich richtig passt also das nötig wärm festzustellen um an Sagen richtigen ort schickt tatsächlich Also ja es sind wir ziemlich traurig die übliche email software die leute verwenden Unterstützt stateles auch nicht also das einzige das wirklich dabei das richtig unterstützt ist microsoft exchange And there is some work to do default incoming Also ja das ist natürlich ein bisschen Arbeit Was natürlich ein richtiges zertifikat haben aber also dabei ausgehend im tale es gibt es wirklich keinen grund wieso Ein email server das nicht einfach machen sollte Also start here less beschützt ein von passiven Überwachen aber sonst nichts also schützt einem nicht vor aktiven angriffen Also wenn ich jetzt ein aktiver angreifer bin Wie würde ich jetzt start here less umgehen also wie kann ich alle die server überwachen die start here less verwenden Stateless way of doing this is you watch for smtp connections Also das einfachste ist wenn man smtp Sessions überwacht und einfach alle diese start here less anfangen ersetzt durch müll Also wenn es da kommt ich unterstütze kompensionen oder so dann ja ersetzt sich das einfach durch Xxxx und der klein sagt er nahe xxxx kenne ich nicht das unterstütze ich also nicht und und der klein schickt dann ja es kann sein dass der Klein trotzdem einfach schicht ich ignorier das aber schicke trotzdem start here less und als angreifen muss man das natürlich in die andere richtung da ich auch ersetzen Das tönt so wie der dümmstmögliche angriff den man sich Ausdenken könnte also aber also kann man das irgendwie etwas subtiler etwas versteckter machen Also schauen wir mal an was der anteil von nachrichten negen wir einfach kuddle model sind Von diesen ip adressen schauen wir uns das mal an also ist unglaublich hohe anteil Also lasst euch das einfach mal euch werken 96 prozenter e-mails aus tunisien Sind verhindert tls zu wenn durch irgendein netzwerk gerät dazwischen weil es das start here less komando Korumpiert und das sind die top 10 länder wenn man zieht top 20 anschaut Seht man dann ja da kommen jetzt langsam die europäischen länder auch Also man fragt sich wieso passiert das ist das bösartig Sind das länder die e-mails entschlüsseln wollen Sitz nicht einfach mal so klar Also wenn man jetzt da fern anschaut dann sieht man irgendwie alles und man sieht das sysco das auch tatsächlich als feature verkauft Also sysco hat diese sysco a rc geräte sysco firewalls und Die wollen natürlich dass man e-mails anschauen kann die über dieses gerät gehen um zum beispiel dann nach melwood zu suchen oder spam Das können die natürlich nur machen wenn sie auf den plaintextes e-mails zugreifen können also deshalb Korumpieren die start here less befehle und dann wird das e-mail im klartext geschickt Das heißt natürlich ja jedes e-mail das aus deinem lang kommt ist natürlich Im klartext verschickt also ja das ist nicht wirklich so erklärt in der sysco dokumentation dass es diesen großen nachteil hat aber ja Es gibt natürlich bessere lösungen also man können zum beispiel im sysco gerät Die verbindungen terminieren und dann start here less nach außen machen das ist dann natürlich nicht end to end Ja, aber es werden nicht alles einfach im plaintext geschickt Mit zweiter wegen in diesen angreif machen könnte es einfach zu lügen was der mail server ist also wenn ich jetzt den mx record für mein mail server rausfinden will dann Weil jetzt ja eh niemand die antworten überprüft hier und die zertifikate überprüft Gibt es nichts dass mich da davon hindert als dns server einfach zu lügen dass mein mail server eigentlich unter dieser ip adresse verfügbar ist Also ja und dann wird halt das ganze e-mail umgeleitet über diesen anderen host und ja vielleicht merkte eigentlich im mail server dass das e-mail verloren gegangen ist aber mittlerweile habe ich zugreifen auf den ganzen inhalt und wir haben uns das noch mal angeschaut Und haben die dns server im gesamten internet betrachtet Und wir haben uns den ganzen open resolve was angeschaut was ist der mx record und was ist die ip adresse für gmail.com und wir haben dann festgestellt dass in hunderten Fällen das in 60 in über 60 ländern das dass das alles irgendwie nicht gestimmt hat und wir sehen das halt ein gewisser antheil halt von gefälschten absendern kam aber das ist halt nur eine untere untere schwelle und Wir sehen halt es pass das passiert tatsächlich wir wissen halt nicht wie viel das passt wir haben nur diesen gewissen einblick in diese problematik aber wir sehen dass es tatsächlich real ist und der zustand Sicherheit auszuliefern ist halt nicht so toll und wir Wir wissen das halt aktive Angreifer dazu fähig sind Verbindungen zu korumpieren und zu beeinflussen Was ist jetzt mit emails emails authentifizieren und Authentifizierung von email ist wesentlich bekannter und relevanter wegen spam oder spam verhinderung und Es geht halt darum dass email provider bei den nachricht empfangen das überprüfen können Ob diese der sender tatsächlich autorisiert war das von der quail domain zu fast schicken Und das ganze soll natürlich dazu sein um spam zu verhindern Und es gibt im prinzip drei protokolle die heutzutage verwendet werden spf dkim und SPF ist das einfachste es erlaubt ein Es ermöglicht eine domain ein dns text eintracht zu veröffentlichen wo dann drin steht dass Das sind die IP adressen die ich kontrolliere die ich besitze Und das sind auch die IP adressen von den SMTP servern und alle anderen emails von anderen SMTP von anderen servern sind halt nicht von mir und und wenn man dann halt eine email kriegt von anderen adresse dann von anderen IP kriegt dann wird die email halt direkt verworfen und Und das ist in der realität durchaus eine effektive metode Also es kriegt halt eine nachricht schaut sich die IP adresse an und Und man und es schaut sich dann halt an ob es von dem host tatsächlich gesendet wurde Für die In der regel werden diese emails halt nicht direkt verworfen sondern sie verwenden es halt in die karte dafür dass etwas spam ist oder nicht und Also es ist mir auch schon passiert dass ich ein email adresse bei meiner email adresse bei meiner Uni habe und und Wenn meine wenn wenn der email server eine strengeregeln hätte dann wären die meisten imet hat einfach weggeworfen worden und das ist natürlich auch nicht praktikabel das nächste verfahren ist die Kim und was das halt ermöglicht ist dass man ein pappliki im dns eintracht veröffentlichen kann und Dadle damit lassen sich halt daten signifian und Dadurch lassen sich halt ausgesendete nachrichten signieren so dass sichergestellt wird dass ein email tatsächlich von einem server kommt These are the headers I am decent here the headers that is and that's that's gonna be in hash gebildet und das ist die prübsurme vom body und und Die der empfänger seite schaut dann halt ob der key und die signature übersprünft über einstimm Aber es gibt eine besonderheit über diesen putto koll Aber ist das nicht klar wo der key für die domain abgelegt wurde Also wenn man jetzt fragen würde was ist der die Kim pappliki wo ist er das ist halt Das kann halt für jede nachricht unterschiedlich sein wo der key ist Und daher weiß man nicht daher weiß man nicht ob eine domain eine email tatsächlich signiert Aber wenn man halt eine signatur raus schmeißt und die entspannend hätte entfernt dann weiß der empfänger nicht dass diese nachricht eigentlich signiert hätte werden sollen So und wir haben ins die Kim eingesetzt aber es hat diese Fatale und eigentlich offensichtlich schwäche dass halt jede angrifft eine eigene signatur verwenden kann Und die meisten Email provider kommen damit zurecht in dem sie halt die antworten der ganzen e-mail server caching und ne checkliste abgehen ob diese nachrichten Entschwinden hätte hat ein entsprechendes signatur und so weiter so fort um halt das normale verhalten von e-mail Servern zu übertragen Dann gibt es noch die mark und es ist Okay, ich anmerkungsübersetzung ich bin jetzt gerade nicht in der hergekommen Also jede asie ist protokoll Erfordert dass jede email tatsächlich eine signatur Angenkt haben muss um als valide anerkann zu werden und policy Jedenfalls versucht der empfänger dann aufgrund dieser signatur zu überprüfen ob die e-mail tatsächlich von dem server kam Von der perspektive von gmail funktioniert das ziemlich gut über 90 prozent aller e-mails wurden Authentifiziert mit diesem verfahren also mit diesem verfahren mit spf und dkm und und Aber das ist dominiert von einer kleinen anzahl von sehr großen Providern wenn man sich die top million domains anschaut und hat man eher einen anderen eindruck Keine 50 prozent haben spf aktiviert und nur ein prozent hat eine die mark policy und von diesen providern und domains Und nur 20 prozent sagen dass es dann rejected werden soll wenn das halt nicht übereinstimmt Die meisten sagen halt die nachrichten werden halt Zum sender zurück gesendet Als inwalt als ungültige nachricht so dass der sender weiß dass er budget gesendet hat aber ob das so sinnvoll ist und Ja das e-mail ecosystem ist leider sehr kompliziert und deswegen wird auch nicht alles eingesetzt und und Anmerk also das problem ist natürlich auch wenn man es mailing listen einsetzt dann hängen e-mail mailing list der meistens immer noch Futter an jede nachricht um zu sagen das ist von dieser dieser mailing liste mit dem ansatzgrab linked und dadurch hat sich natürlich die e-mail selbst Verändert und das hat so was invalidiert natürlich die signaturen der e-mails was natürlich auch ein enormes problem ist und und alle diese politiken oder regeln waren deswegen halt weiche versager weil in der praxis gab es halt immer probleme mit der umsetzung oder mit spezial fällen und und Aber in den letzten jahren sind zumindest die reject policies verstärkt im einsatz gegangen so What do we do moving going forward? Also wie machen wir es weiter? Wir sind im schlimmen ort im moment also ja Wir wollen wahrscheinlich wissen dass wir mit dem richtigen messer was Reden wir wollen tls immer verwenden wir wollen wissen dass die miss tatsächlich von daher kommen was sie sagen dass sie herkommen es gibt auch zwei vorschläge in der itf das eine ist smtp strict transport security da geht es im prinzip darum Ähnlich wie bei hsts für https also eine domain kann man sagen Alle nachrichten die du zu mir schickst muss verschlüsselt sein und ich will nicht dass du mir e-mail schickst das nicht verschlüsselt ist Also zum ersten mal kann man jetzt da ziemlich sicher sein dass wenn man den richtigen richtigen public key hat dass man das e-mail Anderen richtigen ort schickt dann hier bei arc geht es darum dass man ein Also ja da gibt es ein key der über dns veröffentlicht ist das ist jetzt natürlich ja dieser key soll zu verändern ist nicht perfekt weil Der dns tracker kann gefälscht sein aber es besser als was wir heute haben Das ersatz für de kim gibt es dieses arc authenticated receive chain also es hilft damit umzugehen wenn Messages geändert werden also zum Beispiel wenn das signature angehängt wird oder so und dann entsprechend der herrsch sich ändert Also ja so geht es darum dass man ein mailing list anbieter als vertranswörter anbieten kann und das macht das ganze flexibler und passend zur echten Welt also diese werden im moment noch entwickelt sind sehr sehr langsam sich in der praxis auszuführen und es gibt hier diesen googletransparenz report um zu zeigen wie gut die Implementation vorankommen Also ja zum Beispiel der Anteil von gmail emails die verschlüsselt sind und auch Aufgeschlüsselt nach anderen email Providern Wir haben so ein dashboard erstellt mit den top server die zum Beispiel start here less verwenden oder eben plötzlich nicht mehr oder eben so korruptiertes start here less haben Ja, das sehen wir dann gute welche betreiber wir dazu drängen müssen das anzupassen Also ja die mail community hat angefangen diese Sicherheitserweiterung einzusetzen aber wir sind noch nicht da wir hin wollen. Wir haben nicht wirklich Schutz vor aktiven angriffen und ja diese passive Schutz hat auch seine nachteile Ich mein ja so lange das so ist Wird es unwahrscheinlich dass leute das voraussetzen dass man verschlüsselt braucht man 75 prozent das noch gar nicht unterstützen Gmail arbeitet daran Im möglicherweise den benutzer anzuzeigen um ob eine email sicher übertragen oder oder nicht um möglicherweise da den druck zu erhöhen es gab noch vorschläge Die noch in Arbeit sind wo es um strict transport security geht um den bestrebungen weiter zu helfen die ja ja jetzt schon da sind aber Wir schauen ja jetzt bin ich offen für fragen nicht Die immer also wie immer Ja stellt euch bitte bei dem mikrofon auf für fragen Go on isc go on twitter Also wenn ihr auf dem stream sei dann geht einfach auf twitter oder ins ir c also irc.heckend.net und dann der channel raute 32 c3 minus Hall minus 2 So jetzt ist die erste frage vielen dank für die nette übersicht auch für die übersicht aus der amerikanischen seite gmail Und in deutschland gibt es halt eine lobby für dafür dass man halt den essig und den einsetzt also in deutschland Und das hast du halt nicht erwähnt Also den ist eine möglichkeit Ja da es geht im prinzip darum öffentlichen geschlüssel zu veröffentlichen also viele leute Denkt nicht das dnsc wirklich Groß Zulauf findet und dass es wirklich sinnvoll ist es einsetzen ist also es gibt sehr wenige die moment die nsc verwenden Wenig als ein prozent der domains und wir benötigen in lösung die jetzt funktioniert die wir jetzt einsetzen können und Ja etwas dass man stück für stück aber auch einführen kann Okay das internet die gleiche frage mikro 4 About Yuba das sts pro vorschlag warum verwendet ihr ein dns jubel statt einem Die es geht jetzt also ich versuch dass man zu paraphrisieren es geht um verstürzelte kanäle zur abfrage von ich glaube den essig information und der frage steller glaubt das wäre sicherer Also im besten fall würde man natürlich beides machen Wir haben gesehen dass bei so many the middle angreif die zugrift zum inhalt haben und Wenn man natürlich das start tls ersetzen kann dann kann man natürlich die andere verbindung auch der anderen inhalt auch ersetzen Und näher bei dns gehts da um das nur mehr zeugings um da gibt's cashings üblichweise ein anderer server Also salt ein bisschen anderer setup ich würde natürlich gerne als beides gemacht wird Mikro nummer eins In Deiner Forschung mit google hast du dich auch mit zertifikat Well evidierung und abgelaufener zertifikat beschäftigt hast Das habe ich jetzt akustisch nicht verstanden Also bin ich sicher was die frage ist Meins, wieso nicht zertifikate valentieren oder aktive Also aktiv ein falsches certificate zu akzeptieren und nicht für Veraltete Schieferen das ermöglicht das verschlüsselung aufrecht zu halt mit also stimmt ich weiß nicht ob ich eine gute antwort habe für dich haben Also die meisten mehr server akzeptieren einfach irgendwas weil alle davon halt open ssl brauchen Außer natürlich exchange und ja gehts hat um die defaults von open ssl also ich nehme an die meisten akzeptieren unsichere Cyphers aber ich habe jetzt keine konkreten zahlen zu hand mit koacht Es scheint das Größere email das größere email provider mehr mehr zu gated communities übergehen Gibt es eigentlich noch eine hoffnung den eigenen email server zu betreiben Ja es wird immer komplizierter jeden tag ein mehr server richtig aufzusetzen Ich weiß ehrlich gesagt nicht wie das aussehen wird in der zukunft also ja es gibt immer mehr die zu cloud anbietern wechseln weil es einfacher ist wir haben diese technologien Einsetzt Ja, so ist ja nicht so dass es profitär wer so man kann die einsetzen wenn man will ist es einfach halt sehr anstrengend und mühsam Und ja das ist halt was man den cloud provider einfach bekommt ja Also ich nehme jetzt mal an das weiter leute zu cloud pro weiter und umsteigen aber es wird immer eine handvoll organisation geben die selber mehr server haben Riech Ich möchte anmerken dass selbst wenn alles richtig macht man kann trotzdem noch black gelistet werden und das ist halt immer noch ein problem Es ist nicht nun es ist nicht nur ein technisches Es ist nicht nur technisch eine technische frage sondern große provider Interagieren On a slide moving forward with Auf dem slide moving forward with SMT pass and Flattice falsch verstanden aber es ist möglicherweise leicht missverständlich offers und Darst an hsts sollte public key pinning unterstützen und Sure, it's similar along the line Asia is is a little bit hsts also so a little bit key pinning Also, you have the right that's here. It's not about key pinning, but yeah sts. Can't understand Is The transport layer security is not actually just one single step in a big whole thing in the perfect world Yeah In the perfect world Had me and ended to end a security so to my spp. I'm a in the practice is not so easy Skip no a very very clean a fresh wind client self and light in the PGP verwenden. They have no gross Ausefordung for sich Yeah, the gross and anbieter Have no problem with that with the Betrugs mails to find no doubt spam and by PGP's in a few meter data in a no We also have clear text, for example, to who it is, or who is in touch with the e-mails. And this is actually an orthogonal problem. So long as we don't have a solution for the end-to-end solution, and we won't have that soon, we have to look at these two sides of the problem. I was wondering if you were looking into the privacy implications. I was wondering if you also looked at the privacy implications. And, for example, Demoid implemented for small domains and if you then got an answer. And if you then asked Google as the third question, if you then... Well, we haven't looked at it yet, but it would be very interesting to look at it. Next question regarding the SMTPS proposal. I don't like that. I think SMTPS is for big providers like Gmail and Yahoo and Microsoft. But if you ask for mail experts, then they don't want to introduce it. Because it's an authentication via HTTPS and you just need a web server to implement it. It's just not for big organizations, but it's not for all mail providers. Yes, that's right. I don't know what the GitHub issue is that you have. And the answer is, it's probably being put into the deck. So it's not like you have to use a new technology. And for me personally, yes, I just understand that we don't have something similar like HTTPS when you have to do that via DNS. Ideally, I would use something like tech with better versions and extensions. That has a proper keyword or properties as well. I mean, they basically just cache stuff and take it off DNS or... It's about DNS technologies that have something to do with text. And caching is stupid. Yes, there are no perfect solutions at the moment. Internet, please. Question from the internet? Maybe it's easier to send the whole provider to secure emails, but maybe decentralization is the best strategy. Again, there are two orthogonal problems. These technologies will be used by small and large providers. What we see, yes, with small providers, maybe not the expertise. So it's not quite everything, but it's not basically a property of technology that prevents you from using it. So you could use it from large to small. So yes, it's a bit of an independent argument. The big ones are bad and the small ones are good. Micro 2. DNS stack. I understand your argument that it's not really used in the park, but it's shown in the slides that there are some big providers that control a lot of email traffic. And if you use the s stack to secure the domains... If you want to use the s stack to secure the domains for connection, then we would have solved a lot of problems that you already mentioned. And wouldn't it be just better to secure the s stack? Applause from the audience. Yes, DNS stack is technically a possibility. I haven't seen many of the big and large providers that use DNS stack. And of course the small ones still have to support it. So yes, technically it's solved the problem, but DNS stack has its own technical problems. And yes, many people would rather have a better solution before they use DNS stack. There are middle and large providers in Germany and they don't really have problems with it. Yes, we have back gate and key-sized devices, and you can say from day one. Yes, the technology had a problem. So yes, and people ask me why should we use it at all? I mean, technologies that use RSA keys, that probably won't be able to use in a few years, is that right? If we do that now, yes, again in a perfect world, we can use any technology that we can use right away. But now we need a better solution that everyone can use. And I mean, I don't tell you to use DNS stack. There is no problem to use DNS stack. I let everyone decide that. So you have to know that. What we have seen now is that not many actually use it. And that tells me that we have to look at other alternatives. And one reason why many people like this talk is because there are many problems with DNS stack in this talk. And DNS stack develops further. That's why I wouldn't stop at the radar. Yes, I mean, of course I'm curious where that's going. Estonishing 18 minutes left for Q&A. Go ahead, number one. Yeah, you were mentioning that... You mentioned that open source, open source, mail sender, usually don't use locks. So I have seen some attempts. I've seen links to emails. I have seen certain applications. I would like to see how this stuff is fixed. So if you know who you have to talk to, I'd be very happy to see how these boxes are fixed. The people that are leaving right now, first of all, you're doing a great job being very quiet. That's nice. And please also take all your trash. Thank you. And now, number four, please. Yeah, so second question as we have so much time. What if I set up my mail server now and... It's completely optional. And can I actually leave it? Because it's actually optional. What should you actually install now? Because it's actually all broken. I mean, I cannot do anything about it, right? I can't do anything about it, right? What's the point now? I mean, you're correct. I don't have to. I don't have to. I don't have to. I don't have to. I don't have to. I don't have to. I don't have to. So how to solve all problems? Yes, go slowly. We can't still generate enough resources. There's still a lot of work being invested. Yes, keep your eyes open. Look how these further suggestions are produced, but as a single supplier? Yes, it' really not a good point. ... cleaning up new SMTP proposals and drafts, that make it not optional or... Yeah, I mean, we're kind of stuck. So you can just wait and I'm also at the point where you are. I can't do anything. So we measured how the world looks and I was now from the academic point of view, I was able to say the measure, to show the people that what we have to pay attention to, so 80% of the e-mails are not closed. That's just unacceptable. But it's just like HTTP and HTTPS. It's just going to take time to find the right way. Applause for the audience. Micro 1. Most of the e-mails are now authenticated. And everyone has their own spam filter solution. Do you know any open or global solution for spam or spam distribution? Yes, I think there are some, but I don't really know the name. So there's a spam house, for example, lists of IP addresses. There are different providers. Many of the commercial providers are just a business secret. How does it work? So Yahoo or Gmail can say, yes, we have more spam. It's of course a sales argument for these companies. So I don't have the right big companies from which I know they then say, yes, that's exactly how we do it. So maybe the mail server provider can give you a list of stuff they do, but I don't know. One question from the internet. Some problems that the email enterprise has to DNS problems. A few problems for DNS, for email connections, has something to do with DNS problems. DNS stack is not really spread yet. I think everyone else does about the DNS space. I think we've talked about DNS stack for quite a while. We still haven't seen massive deployments of it. So we have, well, that's all in the development with DNS solutions based on technologies. And we don't have any final solutions yet. So there are some solutions for some problems. And some people say that DNS is not the place where you should solve the problems. And you want to have end-to-end solutions that are not based on whether the DNS is broken or not broken. And the question is, of course, there are also the moral factors and, well, the microphone 4. The last time I looked at it, there weren't many discussions about the current state of it. I think it's publicized that it happened in 2015 or something like that. So if it's not closed yet, then it's definitely as far as people can use it today. Question from the internet? You said there's no easy solution for end-to-end encryption in the near future. Have you ever heard of Pretty Good Privacy? Pretty Easy Privacy. Or Pretty Easy Privacy? PGP? P-E-P. So not PGP, but P-E-P to set up end-to-end encryption for you. Very simple end-to-end solution for email. No, I haven't heard of it yet. Micro 4? Your enlightened talk. Do you have any best practices? So advice, like in the paper? I mean, I think the best practices have been outlined by the mail community. The best practices were actually already shown by the mail community. So yes, use these protocols, use them, use them, mark them, and set the start here less. The best practices are to enable these protocols. Yes, that's where we are now. Just switch these protocols on. And above all, it's very specific. And big providers work differently. So read over it and think about what makes sense to you. Anybody else? This is such a long Q&A. Oh, number five, go ahead. Micro 5. Do you have suggestions for tools and web pages where you can test your own mail server, or do you Google for them? I don't know the name of it, but you Google. There's a couple of different domains. On the website. I don't have a name right now. Yes, there are such tests. Please, once again, thanks, Sakir.