Internetbedrijven willen e-mailbeveiliging via smtp verbeteren

Meerdere bedrijven, waaronder Google, Yahoo en LinkedIn, hebben een voorstel aan de Internet Engineering Taskforce gestuurd voor het beter beveiligen van e-mail. Zij stellen een alternatief voor de ontoereikende starttls-protocolextensie voor.

In het voorstel worden verschillende problemen met het huidige e-mailverkeer onder de aandacht gebracht. Dat verloopt op dit moment namelijk via het smtp-protocol uit 1981, dat afzenders niet authenticeert en berichten ook niet standaard versleutelt. Dit blijkt onder andere uit een onderzoek van Google en twee Amerikaanse universiteiten. Later zijn er beveiligingsmogelijkheden aan het protocol toegevoegd, zoals starttls, spf, dkim en dmarc.

De implementatie van deze protocolextensies gebeurt volgens de onderzoekers volledig op vrijwillige basis, wat leidt tot een 'lappendeken van beveiligingsmaatregelen'. Een van de bevindingen van het onderzoek was dan ook dat van de 700.000 smtp-servers, die gerelateerd zijn aan de populairste 1 miljoen websites volgens Alexa, 82 procent tls ondersteunt en maar 35 procent op de juiste manier geconfigureerd is om serverauthenticatie te ondersteunen. Google meldt zelf dat 83 procent van uitgaande en 69 procent van inkomende Gmail-berichten is versleuteld.

Het voorstel, dat afkomstig is van Google, Comcast, LinkedIn, Yahoo, Microsoft en 1&1 Mail & Media Development, richt zich op de tekortkomingen van het in 2002 geïntroduceerde starttls. Dat werkt door een smtp-verbinding met een server tot stand te brengen en dan met het starttls-commando een versleutelde tls-verbinding via een handshake te initiëren. Een server wordt daarbij echter niet geauthenticeerd en als er geen starttls-ondersteuning aanwezig is, wordt het bericht onversleuteld verstuurd.

In die twee feiten liggen volgens de indieners van het voorstel dan ook de tekortkomingen van het systeem. Zo kan een aanvaller via een downgrade-aanval het starttls-gedeelte van een smtp-sessie verwijderen, waardoor de communicatie onversleuteld plaatsvindt, terwijl beide partijen misschien wel tls ondersteunen. Daarnaast kan een aanvaller door het gebrek aan authenticatie zichzelf voordoen als de mailserver van de ontvanger, bijvoorbeeld door de dns-mx-record te spoofen.

De oplossing ligt volgens de indieners in een nieuw systeem, genaamd smtp sts oftewel smtp strict transport security. Dat moet het mogelijk maken dat een domein van tevoren aangeeft of een mta, zoals een mailserver, tls ondersteunt en welk beveiligingsbeleid gehanteerd wordt. Daardoor moet bijvoorbeeld een downgrade-aanval voorkomen kunnen worden.

Ook moet smtp sts ervoor zorgen dat een server geauthenticeerd kan worden. Ten slotte is het ook mogelijk om een beleid op te stellen voor als er geen tls-verbinding tot stand gebracht kan worden. Het voorstel spreekt de voorkeur uit om in dat geval de verzending van de mail als failure te beschouwen. Er is voorzien in een mogelijkheid om dit soort incidenten te rapporteren.

Een reference implementation van smtp sts is beschikbaar via GitHub. Deze wordt onderhouden door twee medewerkers van 1&1 Mail & Media Development die ook betrokken waren bij het ingediende voorstel.

versimpelde weergave van de werking van het huidige smtp-proces

Reacties (105)

Wat mij verbaast aan dit voorstel is het volgende.

Als een van de redenen voor een nieuwe methodiek wordt de mogelijkheid van DNS spoofing genoemd.
Echter, in de referentie opzet zoals die op GitHub te zien is, wordt er nog uitvoerig steeds gebruik gemaakt van DNS records.
Naast de reguliere records (A/MX) en de extra records voor bv SPF, komen er dus nog meer records bij.

Dus, om je, onder andere, te beschermen tegen onvertrouwde mail door gespoofde MX records ga je een systeem opzetten dat vertrouwt op diezelfde DNS antwoorden?
In de draft staat expliciet genoemd dat ze gekozen hebben om DNSSEC niet te vereisen.
Het is dus een bewuste keuze om het gevaar van DNS hijacking toe te staan.
En tegelijkertijd verwijten ze andere bestaande methodes dat deze opties aanbieden maar niet verplicht stellen.

Ik ben erg voor verbeteringen, maar dit is er weer een die iets moois belooft, maar net niet ver genoeg doorpakt om de problemen echt op te lossen.

Als een van de redenen voor een nieuwe methodiek wordt de mogelijkheid van DNS spoofing genoemd.
Echter, in de referentie opzet zoals die op GitHub te zien is, wordt er nog uitvoerig steeds gebruik gemaakt van DNS records.
Naast de reguliere records (A/MX) en de extra records voor bv SPF, komen er dus nog meer records bij.

Dus, om je, onder andere, te beschermen tegen onvertrouwde mail door gespoofde MX records ga je een systeem opzetten dat vertrouwt op diezelfde DNS antwoorden?

STS is een "beter dan niks" oplossing. Het lost niet alle problemen op maar werkt in de meeste gevallen correct. Om het echt goed te doen heb je DNSSEC en DANE nodig maar dat is voor de meeste nog een brug te ver. STS is vrij eenvoudig te implementeren en kan ons helpen om de moeilijke periode te overbruggen.

Dit probleem bestaat ook bij HSTS, de HTTP-veriant van dit protocol. Toch ondersteunen de meeste grote browsers en sites het omdat het in praktijk meestal goed werkt. Een paar zwakke plekken is beter dan helemaal niks.

oeps, verkeerd

[Reactie gewijzigd door CAPSLOCK2000 op 23 maart 2016 13:05]

Eindelijk, want momenteel is het runnen van een mailserver bijna een fulltime job met al die verschillende zaken zoals DKIM, SPF, DMARC, IPv6 zaken die dan niet meer kloppen, ... Een nieuw en eenduidig secure protocol is meer dan welkom.

Dan wordt het eindelijk weer mogelijk om een eigen mailserver op te zetten zonder er fulltime mee bezig te moeten zijn. Gewoon regelmatig updaten en that's it. Nu moet je bijna continu je DNS gegevens updaten, server updaten, clients updaten, ....

Hoewel je gelijk hebt dat het runnen van een mailserver niet meer zo simpel is als het ooit was (vooral ter bestrijding van spam), ik vrees dat deze standaard het er niet makkelijker op gaat maken. Het is feitelijk nog weer wat extra records en een certificaat die voor meer configuratie zullen zorgen.

Wel voor een goed doel overigens, SMTP downgrade technologie komt best veel voor onder dubieuze regimes en het zal vast ook niet erg complex zijn voor MITM aanvallen met commercieel oogmerk.

Het hopen is dat deze SMTP-STS implementatie ook snel in Postfix etc. zal verschijnen om de configuratie zo makkelijk mogelijk te houden.

Wat ik een beetje mis is de terugkoppeling mbt spam. Momenteel moet je je aansluiten bij talloze verschillende systemen en clubjes wil je dat een beetje goed regelen. (Bijvoorbeeld: https://help.yahoo.com/kb/SLN3438.html ).

Ik had graag gezien dat dat in SMTP was opgenomen. Een los protocol kan ook, maar dan zal je zien dat niemand het implementeert. Geintergreerd in de SMTP server kun je ook meteen geautomatiseerd gebruikers throttlen of blokkeren, etc. Gemiste kans wat mij betreft.

De reden om zoiets niet in de standaard op te nemen is om dat dit afleidt van het doel.

@Maurtis idd, had er nog niet zo op ingelezen. Inderdaad nog wat extra records. Jammer dat het niet wat simpeler kan.

Het is wel meer eenmalige configuratie, maar daarna zal het veel lastiger zijn om er misbruik van te maken. Waardoor de uren qua beheer flink omlaag kunnen.

Het voorstel is niet het vervangen van het protocol maar juist weer een extra toevoeging op de oude lappendeken. SMTP in z'n geheel vervangen zal niet zo snel gebeuren. Dan moeten immers alle mailservers op het web het gaan ondersteunen en daar zijn er nogal wat van. Waarvan een groot deel waarschijnlijk de mogelijkheid niet heeft om het te ondersteunen omdat ze vastzitten aan een bepaald softwarepakket waarvoor ze dure nieuwe licenties aan zouden moeten schaffen voor een update (voornamelijk bij microsoft servers, juist een van de partijen die meedoet met dit voorstel).

Waar we vooral voor op moeten passen zijn vervangingen die van het open mailsysteem een besloten vendor-specifiek maken. Juist de genoemde bedrijven hebben daar een handje van...

Als we zo graag een soort email 2.0 willen dan maken we dat toch gewoon? Er komt ook om de zoveel tijd een nieuwe HTML-standaard die dan alle browsers op alle client pc's moeten ondersteunen. Het lijkt mij niet heel veel lastiger om mailservers ook te upgraden naar een moderner systeem. Mailservers vergen nu eenmaal onderhoud en een flinke upgrade is m.i. decennia later echt niet teveel gevraagd. Zeker niet als onze privacy in het geding is.

Zoals het nu is, doe ik niets serieus met email. Een enkele serieuze afzender heeft bij mij pech gehad omdat ik er simpelweg niet op reageer. En als ze vragen waarom dan stel ik altijd de tegenvraag hoe ik zeker kan weten of die email wel van hen afkomstig is. Dan kunnen ze zelf het antwoord wel invullen.

Zoals het nu is, kan email wat mij betreft dood verklaard worden.

Als we zo graag een soort email 2.0 willen dan maken we dat toch gewoon?

Het grootste probleem is ook de sterkste punt van SMTP. Dat punt is dat iedereen met iedereen kan communiceren. Zodra je een e-mail 2.0 gaat introduceren krijg je een splitsing waarbij dat niet meer mogelijk is. Dan valt het belangrijkste voordeel weg en heeft het hele systeem geen zin meer.

Email 2.0 heet toch zo omdat alle voordelen van email behouden blijven maar met toevoeging van beveiliging en authenticatie? Genoeg servers en protocollen krijgen regelmatig updates en daarbij ontstaat ook geen splitsing. SPDY is bijvoorbeeld HTTP2 geworden en dat heeft ook niet voor een tweedeling gezorgd. Sinds het IE6-debakel zijn browsers-bouwers toch min of meer de officiële standaard weer gaan hanteren. Sindsdien zie ik weinig initiatief om weer een eigen propriëtaire standaard te produceren. Als email 2.0 degelijk zou worden ontwikkeld met W3C als neutrale partij dan kan dat toch prima in goede banen geleid worden lijkt mij. Adoptie van de nieuwe standaard door servers en clients is dan slechts een kwestie van tijd.

SPDY is bijvoorbeeld HTTP2 geworden en dat heeft ook niet voor een tweedeling gezorgd.

Ik ken niemand die alleen HTTP2 aanbiedt. Iedereen doet beide en het zit er voorlopig niet naar uit dat HTTP1 al uit kan. Een groot verschil is dat een moderne browser nog steeds een oude webserver kan bezoeken. Voor gewone gebruikers is die verandering onzichtbaar.
Een ander groot verschil is dat HTTP direct loopt van webserver naar webbrowser en het verkeer loopt altijd in dezelfde richting. De wereld van mailservers zitten er vaak verschillende stappen tussen verstuurder en ontvanger. Als er halverwege iets mis gaat kun je niet aan de gebruiker vragen wat hij wil.

Als een nieuw mail-protocol betekent dat je geen mail meer kan ontvangen van oude servers en/of geen mail meer kan sturen aan de meeste mensen in je adresboek dan zie ik het geen succes worden. Als het wel backwards-compatible is dan is het ook compatible met het probleem: spam.

HTTP1 zal nooit uitsterven omdat een bende slimmerds bedacht hebben unencrypted http2 niet te willen ondersteunen.

Zodra certificaten echt makkelijk en gratis zijn (letsencrypt is al best ver op weg), zal dat ook niet meer uitmaken.

De oplossing:

Google moet even zeggen dat sites zonder e-mail 2.0 minder hoog in de ranking komen, binnen no time alles over.

Gebeurde ook met ssl)

Zo gaat dat niet werken, SMTP is niet net als een browser HTTP gebruikt in gebruik. Zie het een beetje als GPRS: alleen om dat mensen het minder of niet meer gebruiken maakt nog niet dat het niet bruikbaar is of niet werkt. Dat het voor mensen niet werkt is vooral vervelen voor mensen.

Eindelijk, want momenteel is het runnen van een mailserver bijna een fulltime job met al die verschillende zaken zoals DKIM, SPF, DMARC, IPv6 zaken die dan niet meer kloppen, ... Een nieuw en eenduidig secure protocol is meer dan welkom.

Dan wordt het eindelijk weer mogelijk om een eigen mailserver op te zetten zonder er fulltime mee bezig te moeten zijn. Gewoon regelmatig updaten en that's it. Nu moet je bijna continu je DNS gegevens updaten, server updaten, clients updaten, ....

Vergeet het maar, dit protocol komt er bij maar al die andere systemen blijven gewoon bestaan.

Het vervelende is dat het naast de huidige structuur niks oplost of iedereen in de gehele wereld moet over...

Het vervelende is dat het naast de huidige structuur niks oplost of iedereen in de gehele wereld moet over...

Daar ben ik het niet mee eens, het doorbreekt de huidige impasse.
Momenteel zit iedereen met het probleem dat onze mailservers wel SSL/TLS ondersteunen maar je het niet kan afdwingen. Er zijn te veel oude systemen met compatibiliteitsproblemen. Daardoor is iedereen gedwongen om alles te accepteren. Iedere aanvaller kan zo'n oud en onveilig systeem nabootsen en zo alle moderne beveiliging omzeilen.

Dit protocol maakt het mogelijk om SSL wél af te dwingen bij servers die aangeven dat ze het ondersteunen. Hopelijk bereiken we na een paar jaar een situatie waarin de meerderheid van de mailservers via STS laat weten dat ze klaar zijn voor moderne crypto. Misschien komt er dan ooit een dag dat we ondersteuning voor oude en onveilige protocollen kunnen laten varen.

Dat klopt, maar dit is setting nr. 5 die je moet instellen voor een enkele domein op een DNS, het mooiste zou zijn als er gewoon een verzamel instelling is voor dit soort dingen.

Echter dit zal ook niet direct werken omdat eerst beide partijen dit nodig hebben wil het werken.

DKIM en SPF hoef je maar 1x te doen als je het goed doet. dkim (en heb je een DKIM generator voor nodig/online prima te vinden) is een dns entry, en spf mits goed ingeregeld is 1 txt record in je dns.

Het grote(re) probleem is dat heel veel IT'ers te weinig kennis hebben van smtp en via een google'tje de settings in de mailserver stoppen. Daarnaast is het investeren in een losse spamfilter vaak een (geld)probleem en klust men maar wat raak met tools op de server zelf met alle gevolgen vandien.

Het is meer een EN EN verhaal dan een OF OF...

Wat google voorstelt om je DNS leading te maken voor het opzetten van de eerste communicatie is leuk, maar dan mag je straks voor allerlei subdomeinen ook nog is settings doen terwijl je eigenlijk wil dat de server onderling dit oplost, een HELO doen (met check), vervolgens tegen elkaar roepen, joh encryptie doen? tuurlijk is goed,...om vervolgens de authenticatie te starten > bericht geving > goodbye....

Wat wel irritant is door de komst van SPF vooral heel veel mailing bedrijven entry's laten opnemen in DNS en zich dus kunnen voordoen als je @jebedrijf.nl en als nog die klote reclame mail kunnen afleveren.


edit: typo verwijderd

[Reactie gewijzigd door itlee op 23 maart 2016 12:55]

Dat is mooi en klinkt gemakkelijk, wil je bij ons even de 100.000 domeinen komen doen ?

in jouw geval had ik dus geen DKIM gebruikt maar t gewoon via SPF opgelost. DKIM is een extra'tje, als je SPF in orde hebt doen de grote der aarde gewoon je mail accepteren...

DKIM is zeker geen extratje, DKIM zorgt er voor dat je zeker weet dat het bericht verzonden is door de server die daar geautoriseerd voor is, in verschil met SPF die alleen zegt dat een server het mag versturen.

Meer info:
https://nl.wikipedia.org/wiki/DomainKeys_Identified_Mail

Bij 100.000 domeinen wordt het alleen maar makkelijker, dan is het namelijk prima te verantwoorden om het goed te scripten. Bij Microsoft Office 365 wordt het ook gewoon aangeboden.

Als je verwacht dat het hiermee minder werk wordt, dan verwijs ik je naar https://xkcd.com/927/.

Dat gezegd hebbende, dit kan best potentie hebben om van plain text smtp af te komen.

En ervoor zorgen dat mail-providers zoals Hotmail en Google je niet blocken, omdat toevallig iemand in dezelfde IP-block spam verstuurd.

Ik draai een mail server en heb nog nooit mijn dns moeten updaten na het initieel instellen...
Verder is het wél gekomen dat je nu zal kunnen aangeven dat secure moet..

Eindelijk, want momenteel is het runnen van een mailserver bijna een fulltime job met al die verschillende zaken zoals DKIM, SPF, DMARC, IPv6 zaken die dan niet meer kloppen, ... Een nieuw en eenduidig secure protocol is meer dan welkom.

Dan wordt het eindelijk weer mogelijk om een eigen mailserver op te zetten zonder er fulltime mee bezig te moeten zijn. Gewoon regelmatig updaten en that's it. Nu moet je bijna continu je DNS gegevens updaten, server updaten, clients updaten, ....

Het kan nog steeds simpel hoor.
Via je MX records laat je mail op je eigen server binnen komen, maar verzenden doet je mailserver dan via de SMTP server van de club waar je je domain afneemt.
Zo stuurt mijn Exchange server de mail via een smtp server van Antagonist.
Die Antagonist server heeft toch alles al geregeld (spf etc) om vanuit mijn domain mail te mogen versturen en ik hoef de smtp server van mijn provider niet te gebruiken (connectie over TLS natuurlijk).

https://internet.nl/ helpt hier misschien?

Wij ervaren in toenemende mate problemen bij het bezorgen van email aan Gmail en Hotmail. Ze filteren steeds strenger, een normaal SPF record voldoet al lang niet meer. Wij zijn een klein bedrijf en hebben geen tijd, of liever gezegd geen zin, om alle andere zaken uit te zoeken en te implementeren. Email versturen is slecht een van de vele zaken die wij doen.

Het is mijn indruk dat de grote mail providers het opzettelijk steeds moeilijker maken. De hulp die ze bieden, als mail niet aankomt, is minimaal. In eerste instantie is dit natuurlijk bedoeld om er voor te zorgen dat er geen spam bij de gebruikers aankomt, maar prettig bijeffect is dat op deze manier kleine spelers uit de markt gedrukt worden. Door zelf een nieuw protocol voor te stellen versterken ze dit effect alleen maar.

Moet ik mijn gebruikers maar gaan adviseren mail via de ISP, Gmail of Hotmail te gaan versturen?

[Reactie gewijzigd door rijnsoft op 23 maart 2016 12:31]

Ik deel je gevoelens over mail maar dit protocol speelt daar geen rol in.

Wij ervaren in toenemende mate problemen bij het bezorgen van email aan Gmail en Hotmail. Ze filteren steeds strenger, een normaal SPF record voldoet al lang niet meer. Wij zijn een klein bedrijf en hebben geen tijd, of liever gezegd geen zin, om alle andere zaken uit te zoeken en te implementeren. Email versturen is slecht een van de vele zaken die wij doen.

Het wordt inderdaad een steeds groter probleem. Voor kleine mailsystemen is het heel vervelend aan het worden.

Het is mijn indruk dat de grote mail providers het opzettelijk steeds moeilijker maken. De hulp die ze bieden, als mail niet aankomt, is minimaal. In eerste instantie is dit natuurlijk bedoeld om er voor te zorgen dat er geen spam bij de gebruikers aankomt, maar prettig bijeffect is dat op deze manier kleine spelers uit de markt gedrukt worden.

Ik geloof niet dat het opzet is, aan e-mail zelf is niet zo veel te verdienen. Het gaat gmail om de gebruikersdata. Alles wat ze moeten doen om hun gebruikers te ondersteunen is winstverlies.

Door zelf een nieuw protocol voor te stellen versterken ze dit effect alleen maar.

Gelukkig hebben ze het goed gedaan en er een net open protocol van gemaakt. Iedereen kan dit zelf implementeren. Heel ingewikkeld is de standaard niet dus ik zie dit niet echt als een barriere.

Het niet ondersteunen van dit protocol zou geen kwaad moeten kunnen. Sterker nog, ik denk dat je dat niet eens betrouwbaar kan detecteren. STS is niet meer dan een hint dat de server ondersteuning biedt voor SSL en daar graag gebruik van wil maken. Het is aan de client om daar naar te luisteren of niet, de server heeft niks te kiezen. Beheerders die willen afdwingen dat er altijd SSL gebruikt wordt kunnen dat nu al configureren. STS voegt daar niks aan toe (en neemt ook niks weg). Het is een vrijblijvende suggestie, niet meer.

Het niet ondersteunen van dit protocol zou geen kwaad moeten kunnen. Sterker nog, ik denk dat je dat niet eens betrouwbaar kan detecteren. STS is niet meer dan een hint dat de server ondersteuning biedt voor SSL en daar graag gebruik van wil maken. Het is aan de client om daar naar te luisteren of niet, de server heeft niks te kiezen. Beheerders die willen afdwingen dat er altijd SSL gebruikt wordt kunnen dat nu al configureren. STS voegt daar niks aan toe (en neemt ook niks weg). Het is een vrijblijvende suggestie, niet meer.

Volgens mij klopt die analyse niet. Jij beschrijf het probleem met het huidige protocol. Een server kan wel aanbieden over TLS maar als de ontvangende server (of een MITM!) zegt het niet te ondersteunen gaat het alsnog plain text. En SMTP kent op dit moment geen methode om dan af te breken. Daarom heet het ook "Opportunistic encyption", we doen encryptie waar het kan maar als het niet dan doen we het plaintext.

Daar moet SMTP-STS nou juist verandering in aanbrengen door het niet meer vrijblijvend te maken. Als de ontvangende server geen TLS accepteert dan zegt de versturende server, "OK, dan verbreek ik nu de verbinding" met de mogelijkheid voor een foutmelding richting te client. Dat is toch wel degelijk een verbetering ten opzichte van nu.

[Reactie gewijzigd door Maurits van Baerle op 23 maart 2016 13:05]

Daar moet SMTP-STS nou juist verandering in aanbrengen door het niet meer vrijblijvend te maken. Als de ontvangende server geen TLS accepteert dan zegt de versturende server, "OK, dan verbreek ik nu de verbinding" met de mogelijkheid voor een foutmelding richting te client. Dat is toch wel degelijk een verbetering ten opzichte van nu.

Dat is een kwestie van perspectief. Voor de ontvangende server verandert er niks. De versturende server kan zelf kiezen of hij STS respecteert of niet. Daarom noem ik het vrijblijvend.

Het wel of niet ondersteunen van STS zou geen invloed moeten hebben op de kans dat een mail aankomt of niet. Het het beschermt tegen MITM en spoofing-aanvallen maar het zegt niks over of een mail spam is of op een andere manier niet betrouwbaar.

PS. Lees bovenstaande aub in de juiste context, namelijk als reactie op rijnsofts angst dat dit protocol gebruikt gaat worden om kleine spelers uit de markt te drukken.

Op die fiets, vanuit de ontvangende kant verandert er inderdaad nog niets inderdaad.

Het wachten is op een nieuw server-to-server email protocol dat TLS verplicht stelt. Volgens mij is dat nog niet eens zo moeilijk. Je moet zorgen dat het voor de grote jongens (Gmail, Hotmail, Yahoo, Exchange etc.) genoeg voordelen biedt om het snel te implementeren. Zij kunnen beginnen met alles proberen af te leveren met het nieuwe protocol en terugvallen op SMTP. Tegelijkertijd kunnen ze email die binnenkomt met nieuwe protocol een lagere spamscore geven dan met SMTP zodat er een incentive is voor de rest van de wereld om het nieuwe protocol ook te implementeren. Dan sterft SMTP langzaam uit.

Ik vrees dat dit precies is wat @rijnsoft vreest. Zodra de grote jongens het geimplementeerd hebben zullen ze snel overschakelen op het verplicht stellen van het gebruik van STS, anders accepteren ze je mail gewoon niet meer. Als kleinere speler zul je dus wel moeten investeren, of je de resources heb of niet.

Heb het zelf ook zitten, mijn eigen mailserver kan ik op geen enkele manier nog mails laten sturen naar outlook.com/hotmail. Google gaat gelukkig nog wel. En dat gewoon omdat het een dedi is die een IP heeft in een range waar veel spammers in zitten.

En dat gewoon omdat het een dedi is die een IP heeft in een range waar veel spammers in zitten.

Dat daar veel spammers zitten, zegt waarschijnlijk ook wel iets over het abuse beleid binnen die host/range, dus is van hun uit gezien de kans relatief(!) groot dat jij er ook een bent.
Wil je fatsoenlijk kunnen mailen, kies dan een host met een fatsoenlijk spambeleid.
Van mij mogen ze mail van hosts/ranges met n slecht beleid iig zonder meer blokkeren.
Maarja, het beoordelen van die IP's en het gevoerde beleid, is ook natte vingerwerk en gaat nog wel eens mis natuurlijk, maar daar is niet echt een beter alternatief voor (anders dan meer spam doorlaten).

Een mailserver is geen product dat je installeert en niet meer naar omkijkt. Want als er misbruik van gemaakt wordt, heeft het hele internet daar mogelijk last van. Dus moet je dat monitoren en onderhouden.

Als je niet de resources vrij wil maken om zo'n server actief te onderhouden, kun je je inderdaad beter richten op een dienst waar dit voor je gedaan wordt.

Ik heb nog nooit problemen ervaren met mail versturen naar Gmail of Hotmail adressen en ik heb al 16 jaar een mail bak dus waarschijnlijk doe je iets verkeerd.

Het grote probleem met dit voorstel is dat het ook weer vrijblijvend is en dat werkt dus niet. Als de helft van de wereld niet mee doet moet je nog steeds standaard STMP verbindingen accepteren. Tuurlijk kan ik in mijn mailserver software zeggen dat ik alleen TLS verbindingen accepteer maar dan komt de helft van de mail niet aan. Dat schiet niet op.

Kortom eerst moeten alle neuzen dezelfde kant op en moet TLS verplicht worden en dat begint bij de makers van mailserver software en die moeten instellen dat standaard TLS gebruikt wordt. Daarnaast alle IT-ers een schop onder hun hol geven dat binnen 6-12 maanden iedereen TLS aanzet en per x datum geen cleartext SMTP meer accepteren.

En die STS (strict transport security) is gewoon extra bewijs leveren dat jij bent wie je zegt dat je bent. Zoveel bijzonders is dat niet.

Maar nogmaals als je niet wereldwijd afspreekt het samen op te pakken en het vrijblijvend maakt komt er toch niks van terecht. Het is gewoon laksheid van IT-ers en bedrijven.

Er zijn er genoeg die wel problemen hebben op hun eigen mailserver, dus negeren kun je het niet. En aangezien e-mail vaak een 'gratis' functie is die bij je Webhosting of internet abonnement hoort is al het werk dat je daarin moet steken een kostenpost die je niet kunt uitleggen aan je gebruikers.

Wij zijn een klein bedrijf en hebben geen tijd, of liever gezegd geen zin, om alle andere zaken uit te zoeken en te implementeren. Email versturen is slecht een van de vele zaken die wij doen.

Ik snap je dilemma, maar de vraag is dan ook of je het zelf moet blijven doen.

Email is helaas door alle spam en andere fraude complex geworden. Ik vergelijk dat met de oude tijd toen je met notepad zelf noge en HTML-pagina kon inkloppen, maar nu echt wat betere tools nodig hebt. Niet helemaal analoog geef ik toe, maar zelf email servers beheren is niet meer voor iedereen door de toenemende complexiteit.

Je kunt het dan ook uitbesteden via relay servers.

Ik heb mij vaak afgevraagd hoe je een nieuw mail systeem zou kunnen ontwikkelen (los van het e-mail protocol) dat zorgt dat je geen last hebt van spam. Zoals bij Facebook je eerst vrienden moet accepteren, zoiets ook bij het mail systeem kan gebruiken.

Ik vraag mij af waarom ik niet zoveel last heb van spam via Facebook, mogelijk één bedrijf het beheert en ook alle 'apps' die misbruik kunnen maken van de facebook api zijn met een druk op de knop te disablen. Waarbij de huidige mail decentraal is.

En een ander ding zoals herleiden waar mail vandaan komt, zou dat verbeterd kunnen worden? En DNS servers in duidelijkere clusters opdelen zodat deze makkelijker aan / uit gezet kan worden als uit een cluster massamails worden verstuurd. Klinkt eerder naar een meer beheerde mail dienst.

Iemand anders hier ideeën over?

[Reactie gewijzigd door Mic2000 op 23 maart 2016 12:29]

Het probleem is natuurlijk dat je met email ook berichten wil kunnen ontvangen van mensen waar je nog nooit van hebt gehoord. Zeker zakelijk krijg ik vaak genoeg relevante email van mensen die ik niet kende. Als je dat eerst zou moeten whitelisten zou dat erg complex kunnen worden.

Maar inderdaad, ik loop ook al een jaar of vijftien rond met ideeën wat er allemaal wel niet beter zou kunnen aan email. Ik zou bijvoorbeeld ten eerste het aantal protocollen terugbrengen tot twee. Eentje voor client-server contact en eentje voor server-server contact. Weg met POP en SMTP van client naar server, gewoon een IMAP-achtig protocol voor communicatie (verzenden en ontvangen) tussen client en server. De server stuurt het dan door. Zo hoef een STMP server ook niet meer zomaar verkeer van zomaar een client te accepteren.

Voor server-server gebruik je dan een ander SMTP-achtig protocol met verplichte TLS encyptie en authenticatie.

Verder zou het protocol standaard ondersteuning moeten bieden aan een soort encryptie op messageniveau compleet met PKI zodat een server alleen metadata kan zien (die zal immers nodig zijn voor het afleveren) maar niet de inhoud.

Als bonus misschien nog een systeem dat binair attachments kan versturen. Een beetje zoals Apple Mail Drop, je verstuurd feitelijk een linkje mee naar een bestand in cloud storage.

Maar goed, eigenlijk ben je dan dus een soort open standaard versie van Exchange technologie aan het ontwikkelen. Waar op zich niets mis mee is.

[Reactie gewijzigd door Maurits van Baerle op 23 maart 2016 12:46]

Een optie kan zijn om die mail betalend te maken.

Ja, ik vond dat idee destijds om een fractie van een cent te vragen per verstuurd bericht wel een goed idee. Voor normale gebruikers kost dat op jaarbasis vrijwel niets terwijl het voor spammers ineens erg duur wordt.

Ik heb klanten die >4000 mails per dag versturen... 7 dagen per week. Wordt toch nog een leuk kostenpostje, 14000 euro per jaar...

Ik heb klanten die >4000 mails per dag versturen... 7 dagen per week.

Hey, jij werkt voor spammers.

Misschien moet e-mail niet meer gebruikt worden om berichten op grote schaal te versturen. Een opt-in systeem (bijvoorbeeld gebaseerd op RSS) is voor dat soort informatie efficiënter.

[Reactie gewijzigd door The Zep Man op 23 maart 2016 14:43]

E-mail is daar juist uitermate geschikt voor, helaas kwamen spammers daar ook achter.

Ik zou als klant ook niet moeten denken aan een opt-in systeem voor iedere bestelling die ik bij een (nieuwe) webshop doe. Laat staan als webshop zelf de klantenservice moeten opschalen omdat mensen hun factuur/verzendbevestiging niet ontvangen hebben doordat ze nieuwsbrief en opt-in uitgetikt hebben.

Ik zou als klant ook niet moeten denken aan een opt-in systeem voor iedere bestelling die ik bij een (nieuwe) webshop doe.

Al kost een email bericht een fractie van een cent, dan kan een webwinkel wel die paar mailtjes m.b.t. jouw bestelling gerust wel betalen.

Het voorstel om e-mail geld te laten kosten is om te voorkomen dat een enkele mailserver ongeautoriseerd in bulk mailberichten de deur uit schiet. Immers gaat het de eigenaar dan geld kosten, dus die zal dan wel geneigd zijn om zich hiertegen te beveiligen. Een webwinkel die per dag zoveel mail verstuurd naar klanten wegens bestellingen kan dat heus wel verwerken in de prijs van de bestelling, in de aanname dat het hooguit enkele centen kost.

[Reactie gewijzigd door The Zep Man op 23 maart 2016 14:44]

Nee, niet voor spammers haha alles zakelijk. Bedrijf met >500 werknemers heb je dat al snel, 8 externe mails per dag per persoon is niks.

Nee, niet voor spammers haha alles zakelijk. Bedrijf met >500 werknemers heb je dat al snel, 8 externe mails per dag per persoon is niks.

Een tiende cent per bericht, 10.000 mails per dag... 10 euro moet wel betaalbaar zijn per dag voor een organisatie van die grootte.

[Reactie gewijzigd door The Zep Man op 23 maart 2016 17:08]

Geld moet ergens naartoe gaan, mogelijks naar personen die mail ontvangen.
Als ze veel mail krijgen, zal het uitevenen.

Spam is een kost voor iedereen.

Iets wat steeds meer toegepast wordt is SPF (https://en.wikipedia.org/wiki/Sender_Policy_Framework)
Kort gezegd zegt een domein in zijn DNS welke servers (IP) mails namens dat domein mag versturen. Ander IP == spam.

Als nu iedereen dat zou gaan gebruiken.......

En dan verander je de from (zoals zichtbaar in je mailclient), niet de envelope-from, en je spf heeft geen enkele zin meer.

Dat maakt geen verschil
voor SPF kijkt de ontvangende server naar het IP-adres van de versturende mail-server. Dus niet de mail-server van het from-adres, maar de server die daadwerkelijk het versturen is.
Die kan je niet faken, want dan mislukt de TCP-handshake.

Ik denk dat je je even opnieuw over SPF moet inlezen. Als de envelope-from geforged wordt, kan de boel inderdaad geblokkeerd worden. Als de envelope-from iets compleet anders is maar de "from" (zoals zichtbaar in de e-mail client, dus niet de eigenlijke sender) heeft SPF niets meer te zeggen.

Alleen mail accepteren van mensen die je kent kan tot rare situaties leiden. Bijvoorbeeld: een collega stuurt een mail naar een paar mensen bij een klant die hij kent, maar jij niet. Jij bent ge-cc-ed en krijgt de mail omdat je jouw collega op de whitelist hebt staan. Vervolgens antwoordt iemand van de klant. Wil jij dat bericht dan krijgen of niet? En wanneer wel en wanneer niet? Je zou iets intelligents kunnen bedenken dat als je replied, jij het bericht in ieder geval krijgt, ook al ken je de afzender niet. Maar wat als de afzender alle geaddresseerden kopieert naar een nieuwe mail? Ik denk dat het praktisch onmogelijk is om daar een algemene regel voor te bedenken, omdat iedereen daar anders mee om gaat of wil gaan.

De beste oplossing is denk ik de oplossing die al bestaan: white/blacklisting in de email client. Dan bepaal je zelf wat je wilt doen.
Of een fatsoenlijk spamfilter.

Het nadeel van een centrale dienst is dat iedereen die ene centrale partij moet vertrouwen en dat gaat nooit lukken. Stel dat we Facebook aanstellen als die centrale partij, zou de directeur van Twitter daar lekker bij slapen? Die zal altijd bang zijn dat zijn mail door Facebook wordt onderschept, gelezen of gemanipuleerd. Binnen een land zou je het nog door de overheid kunnen laten regelen maar internationaal gaat dat niet lukken.


Herleiden waar een mail vandaan komt is over het algemeen vrij eenvoudig. Iedere mail bevat headers die het hele pad laten zien. In theorie zijn die headers te manipuleren maar in praktijk heb ik dat nooit gezien.
Met behulp van DKIM kun je ook bewijzen waar mail vandaan is gekomen maar dat wordt nog niet overal ondersteunt.

Als je alleen mail wil accepteren van vrienden dan kan dat nu al. Configureer je mailfilter om alleen mensen uit je adresboek (of een andere) bron toe te laten en gooi de rest weg. Het is dan wel de vraag hoe je aan de adressen van je vrienden komt, je kan ze immers niet mailen.
Op Facebook heeft iedereen een pagina die door iedereen bezocht kan worden met een knopje om vrienden te worden. Binnen e-mail is dat niet echt mogelijk.

Zo'n configuratie botst wel een beetje met de cultuur die rond e-mail hangt. Dat iedereen vrij met iedereen mag mailen zie ik als een van de pluspunten van e-mail. Spam is daar de keerzijde van maar ik accepteer dat.

Een berichtje in je mailbox: "Pietje Puk heeft geprobeerd om je een mail te sturen. Accepteer je Pietje als mailcontact?"
Maar goed, dat wordt dan binnen no-time weer door spammers misbruikt.

We hebben al zo'n centrale dienst, die iedereen vertrouwt. Dat systeem is DNS. En dit nieuwe email-systeem gebruikt DNS precies voor dit doel. In SMTP-STS staat bij je mailserver DNS record vermeld dat jouw mailserver TLS ondersteunt en ook eist.

Dan heb jij niet genoeg spam mails bekeken. Header manipulatie gebeurt vrij veel, specifiek het toevoegen van extra Received headers, om zo de indruk te wekken dat de originele bron van de mail anders is.

Verder is het jammer dat het _weer_ een patch is op SMTP. Ze hadden m.i. beter een compleet nieuw protocol kunnen ontwikkelen dat alle huidige problemen oplost. Nu wordt het een lappendeken over een lappendeken.

Ze klagen nu dat X procent TLS niet of niet goed ondersteund. Als je deze STS oplossing gaat implementeren zul je ook niet direct iedereen achter je hebben. Kortom, je blijft dan met die verouderde rommel zitten.

Dan heb jij niet genoeg spam mails bekeken. Header manipulatie gebeurt vrij veel, specifiek het toevoegen van extra Received headers, om zo de indruk te wekken dat de originele bron van de mail anders is.

Een valse From zie ik vaak, vervalste Received headers zie ik vrijwel nooit. Daar moet ik wel bij zeggen dat ik nogal wat anti-spam maatregelen actief heb die spam vroegtijdig probeert te herkennen. De ergste spam zal ik dus nooit zien omdat die al is afgevallen.

Ze klagen nu dat X procent TLS niet of niet goed ondersteund. Als je deze STS oplossing gaat implementeren zul je ook niet direct iedereen achter je hebben. Kortom, je blijft dan met die verouderde rommel zitten.

Het probleem is dat de huidige situatie uitzichtloos is. Wie z'n mailserver wel "goed" configureert (vanuit beveiligingsoogpunt) is voor een groot deel van de wereld onbereikbaar. Wie goed bereikbaar wil zijn moet z'n mailserver wel opdragen om alles te accepteren, encryptie of niet. Daardoor betalen de "goeden" een hoge prijs waar ze eigenlijk niks voor terug krijgen.

STS biedt een uitweg. Met STS kunnen de "goeden" het voor zichzelf in ieder geval goed regelen. Dat er dan nog een deel van de wereld is dat niet mee doet maakt niet uit, die blijven op de oude voet verder gaan maar de goeden hoeven niet meer te lijden onder de kwaden.

Als je nu een nieuw protocol gaat introduceren zal het ook weer een heeeeeele tijd duren voordat het gros van de mailservers dit protocol ondersteunt, en nog eens een heeeeeeeleee tijd voordat het de standaard wordt en nog eens een heeeeeeeele tijd voordat SMTP uitgefaseerd is. Zelfde probleem.

Eh, dat kan toch al. Ik kan bijvoorbeeld in Zimbra instellen dat ik alleen mails wil ontvangen van de mensen die in mijn adresboek staan (activity streams). Dan komen de overige mails in een aparte forlder en kan ik er zelf nog voor kiezen of ik de andere mails nog door wil spitten of direct weg gooi.

Heeft het in gebruik nemen van DANE (wat al ingebouwd zit in postfix, maar niet gebruikt kan worden door het gebrek aan uitrol + inrichten van DNSSEC) niet hetzelfde functionele doel? Namelijk dat mta's elkaar vertrouwen en veilig mail versturen?

Dit voorstel bouwt voort op het bestaan van DANE. Het werkt ook beter in combinatie met DANE maar biedt ook uitkomst als DANE niet mogelijk is. Bovendien voegt het ook wat extra dingen toe. DANE gaat alleen over transport, SMTP-STS moet ook extra communicatie terug naar de client mogelijk maken. Een melding in de trant van "Bericht kon niet afgeleverd worden omdat geadresseerde geen encryptie ondersteunt".

2.1. Differences from DANE

The primary difference between the mechanism described here and DANE
is that DANE requires the use of DNSSEC to authenticate DANE TLSA
records, whereas SMTP STS relies on the certificate authority (CA)
system and a trust-on-first-use (TOFU) approach to avoid
interception. The TOFU model allows a degree of security similar to
that of HPKP [RFC7469], reducing the complexity but without the
guarantees on first use offered by DNSSEC. (For a thorough
discussion of this trade-off, see the section _Security_
_Considerations_.)

In addition, SMTP STS introduces a mechanism for failure reporting
and a report-only mode, enabling progressive roll-out and auditing
for compliance.
https://github.com/mrisher/smtp-sts/blob/master/spec.txt

En dus hang je toch weer vast aan die CA. Ik vind DANE net een pracht van een uitvinding omdat je in principe die CA eruit zou kunnen halen (al word dat op dit moment nog amper ondersteund).

Eens. Alleen is volgens mij het idee van SMTP-STS dat ze niet willen wachten tot DNSSEC overal ondersteunt wordt. Daar valt wat voor te zeggen natuurlijk.

Niet willen wachten vind ik een zwak excuus. Dat is net als zeggen: we implementeren geen IPv6 omdat niet iedereen over is naar IPv6. Je kan net meer druk zetten bij die diensten die vandaag nog geen DNSSEC ondersteunen op deze manier om de implementatite te versnellen.

We hebben de technoiogie en de grote TLDs alsook vele cTLDs ondersteunen het vandaag al. Het doet ook de afhankelijkheid en de kost van certificaten bij CAs verdwijnen. Dat het voor https niet direct word geïmplementeerd kan ik nog een beetje begrip opbrengen. Maar als je iets nieuws aan het bedenken bent dan moet je imho direct voor een goede oplossing durven gaan.

Indien mail providers dezelfde houding aannemen dan zie ik SMTP-STS trouwens ook maar heel traag aan adoptatie winnen . Want waarom zouden die bedrijven erin investeren? En zolang je geen grote meerderheid hebt die het ondersteunt kan je het ook niet gaan afdwingen.

Heeft het in gebruik nemen van DANE (wat al ingebouwd zit in postfix, maar niet gebruikt kan worden door het gebrek aan uitrol + inrichten van DNSSEC) niet hetzelfde functionele doel? Namelijk dat mta's elkaar vertrouwen en veilig mail versturen?

Ja, DANE kan min of meer hetzelfde. STS is echter een stuk makkelijker te implementeren en zou wat gebruikersvriendelijker moeten zijn.
STS kan ook gebruik maken van DANE als dat beschikbaar is.

Echt ideaal is STS niet, het is vooral een lapmiddel voor een wereld waarin unencrypted de standaard is. Misschien krijgen we in de toekomst een wereld waarin we altijd encryptie gebruiken. Dan kan STS weer worden uitgeschakeld.


correctie

Het duurde even tot ik begreep dat het plaatje onder dit artikel de huidige (simpele) SMTP standaard laat zien en niet waar ze naartoe willen.

Zou het niet zinvol zijn om ook een plaatje te plaatsen van de nieuwe situatie zoals ze van plan zijn?

Ik heb het bijschrift aangepast. Een visuele weergave van de nieuwe situatie kon ik niet opduikelen.

Weglaten is wellicht beter. Op basis van de tekst is de nieuwe situatie af te leiden, maar alleen voor het publiek dat smtp al kent en waarvoor het plaatje dus overbodig is.

Zelf tekenen?

Ik vond het plaatje ook verwarrend. Heb tevergeefs zitten zoeken naar de voorgestelde verbeteringen, maar die komen er dus niet in voor.

Een reference implementation van smtp sts is beschikbaar via GitHub. Deze wordt onderhouden door twee medewerkers van 1&1 Mail & Media Development die ook betrokken waren bij het ingediende voorstel.

Die reference implementatie is nogal karig en bevat alleen wat boilerplate info en geen implementatie. Ze hebben een paar test-servers opgezet maar ik zie geen code/configureatie die dit protocol implementeert op github.

Als de ontvangende partij alleen tls ondersteunt met de hoogste encryptygradaties, zit je toch eigenlijk al goed als ontvanger zelf? Dan weet je zeker dat de mail die naar jou verzonden wordt versleuteld is.

Klopt, alleen loop je het risico dat pak-em-beet 20% van alle email naar jou niet aankomt. En dat is heus niet alleen maar spam.

Inderdaad.. voorlopig dan maar terugvallen op oudere ciphers, en de echte oude niet meer ondersteunen.

Zie https://cipherli.st/#postfixconfig voor de meest veilige instellingen die nog zo veel mogelijk backwards compatible werken.

https://www.htbridge.com/ is een goede site om je ssl verbinding van je mail- of webserver te testen.

[Reactie gewijzigd door twicejr op 23 maart 2016 14:04]

Inderdaad.. voorlopig dan maar terugvallen op oudere ciphers, en de echte oude niet meer ondersteunen.

Je mist echter het punt. Een groot deel van de SMTP-servers ondersteunt geheel géén encryptie. Als voorbeeld de grootste provider van Nederland KPN, ondersteund geheel geen, nada, niks, zip aan SSL/TLS op hun SMTP servers. Dus alles van, naar en via hun servers is dus onversleuteld. Dat is inclusief alle zakelijke klanten die KPN als relay gebruiken! (Dochter XS4ALL is de enige uitzondering.)

Dus door STARTTLS te vereisen verlies je alle email van, naar en via KPN servers. Dat is geen kleinigheid

KPN verdiend een schop onder hun kont.

Je mist echter het punt. Een groot deel van de SMTP-servers ondersteunt geheel géén encryptie. Als voorbeeld de grootste provider van Nederland KPN, ondersteund geheel geen, nada, niks, zip aan SSL/TLS op hun SMTP servers. Dus alles van, naar en via hun servers is dus onversleuteld. Dat is inclusief alle zakelijke klanten die KPN als relay gebruiken! (Dochter XS4ALL is de enige uitzondering.)

Dus door STARTTLS te vereisen verlies je alle email van, naar en via KPN servers. Dat is geen kleinigheid

Controleer eerst even je bewering....KPN ondersteunt (met een t) wel degelijk TLS.

Het gaat niet over TLS, maar STARTTLS. En het gaat daarnaast om STARTTLS in combinatie met inter-server SMTP.

Waarschijnlijk ben je in de war met TLS zoals gebruikt voor client-server communicatie. Daar heeft KPN beperkt support. Wél voor IMAP, niet voor POP3 en ook voor SMTP maar dat laatste weer enkel op het intranet.

Dit voorstel gaat over communciatie tussen mail-servers onderling. Denk aan de communciatie tussen Hotmail en KPN, of tussen een zakelijke server met een KPN relay.

De "check je bewering even" was een tip, misschien moet ik dat even uitleggen: doe eens een telnet op poort 25 naar het MX van kpnmail.nl.

Over dat starttls een manier is om een onveilige verbinding secure te maken met TLS ga ik het niet hebben.

Overigens zie ik dat KPN ook secure POP en IMAP aanbiedt.
En wat je bedoelt met alleen SMTP op het intranet...ik kan gewoon met mijn KPN/kpnmail.nl credentials vanaf ziggo ip's, maar ook van uit het buitenland SMTP servers van KPN gebruiken.
Misschien redeneer je nog uit het verleden.

De "check je bewering even" was een tip, misschien moet ik dat even uitleggen: doe eens een telnet op poort 25 naar het MX van kpnmail.nl.

Misschien zelf even checken. kpnmail.nl (o.a. smtp en mailrelay) is niet de inter-server SMTP, maar de client-server interface voor o.a. SMTP.

Dat men client-server STARTTLS ondersteund is waar - mits op het KPN intranet - maar daar gaat dit artikel dus niet over.

Maar geloof mij niet, geloof Google die in het aangehaalde rapport aangeeft dat 0% van en 0% naar KPN servers versleuteld is. Ligt aan Google?

En tenslotte kijk de volgde keer dat je een email krijgt van KPN eens in de headers.

Sorry, maar lezen is ook een kunst blijkbaar... Ik zei het MX van Kpnmail.nl...

En ik heb natuurlijk al een mail van mijn gmail.com naar mijn kpnmail.nl mailbox gestuurd. Netjes TLS in de Headers.
En ook omgekeerd, van kpnmail.nl naar gmail.com....TLS wederom....
Ik snap je niet
En over welk Google rapport heb je het?
Als beheer en beveiligings expert zou ik het eerst zelf maar even checken of de kpn servers inderdaad geen starttls ondersteunen

De MX van kpnmail zijn maar een deel van de SMTP servers van KPN. Hoe dan ook ik heb het even nagezocht en ben erachter gekomen wat de verwarring geeft: KPN is letterlijk nu bezig met de transitie naar TLS versleuitelde SMTP

Ik beken dai k inderdaad niet de laatste twee weken gehercontroleerd had. Begin maart namelijk toevallig nog wel, en toen was het alelmaal non-encrypted. Ter controle nog wat oude test-emails gezocht van rond begin maart, en inderdaad. Echter een nieuwe test-mail gisteren laat zien dat inkomende email (MX kpnmail) inderdaad versleuiteld is. Uitgaand is nog roulette (en/want gaat niet via het kpnmail domein) en soms versleuteld.

Google laat ook zien dat inm februari zowel inkomend en uitgaand 0% versleuteld was. Nu in maart is inkomend 100% versleuteld, en uitgaand stijgende. Het lijkt samen te vallen met upgrades van hun SMTP software, dus dat zou het verklaren.

Lijkt er op dat KPN dus wellicht binnenkort eindelijk van de "wall of shame af kan".
(Ik hoop dat ze dan gelijk ook non-versleutelde POP3 en IMAP afsluiten.)

ja, zou mooi zijn. Hoe is het trouwens met Ziggo?

Ziggo is al een jaar of twee volledig versleuteld. Wellicht langer, maar ik had nooit eerder gekeken dan twee jaar geleden.

Inderdaad.. voorlopig dan maar terugvallen op oudere ciphers, en de echte oude niet meer ondersteunen.

Het probleem is dat het "voorlopig" nu al 15 jaar duurt en er lijkt geen vooruitgang in te zitten. Door de manier waarop SMTP / TLS werkt is het haast niet mogelijk om een downgrade aanval te voorkomen.
Je kan dan wel goede ciphers hebben geconfigureerd maar voor aanvallers ben je niet beter dan je zwakste cipher, als er niet al wordt gedowngrade naar clear-text.
STS biedt de mogelijheid om het gebruik van goede ciphers af te dwingen als beide kanten daar toe in staat zijn.

Off topic: Goed,... dan gaat mijn volgende spam-aanval maar via PostNL. Levert meteen weer wat werkgelegenheid op

On topic: Dat wordt nog wat met de implementatie voor menig freeware mailservertje zoals Hmailserver, Mailenable, etc. Heeft even geduurd voordat Hmail TLS ondersteunde.

We hebben hier nog een fax staan, en ja daar komt ook nog altijd spam op binnen

Plaatje klop van geen kant

van client naar smtp en van smtp heen en weer naar en van DNS

lijkt me handig om eerst vanaf client naar DNS te gaan anders kom je ook zo lastig aan het name record van de SMTP ....

De client moet inderdaad ook het IP hebben van zijn eigen mail server, maar heeft weinig te maken met wat hier beschreven staat. Het gaat hier namelijk vooral om de communicatie tussen 2 mail servers.

Plaatje klopt wel.
Over het algemeen verstuurd je client de mail naar een uitgaande SMTP server. Deze kijkt wat de MX- en overige records zijn van het domein waarheen je mail wilt versturen, en verstuurd het vervolgens.
Je client zal eigenlijk nooit zelf als verzendende SMTP-server optreden.

Wat wel zo is, is dat je als uitgaande SMTP-server een DNS-naam opgeeft, dan zal je client ook een nslookup doen om het bijbehorende IP-adres te achterhalen. Dat heeft echter niets met de mail flow van doen.

[edit: Blokker_1999 was me voor :)]

[Reactie gewijzigd door AMS76 op 23 maart 2016 13:45]