KPN geeft details over overzetten XS4ALL-colocatiediensten naar KPN

KPN deelt details over het overnemen van de colocatiediensten van XS4ALL. Volgens de provider blijft de dienst grotendeels hetzelfde, hoewel het bedrijf wel een smtp-functie schrapt. KPN meldde in januari al dat het de colocatiediensten overneemt.

De e-mail van KPN.
Klik voor volledige grootte

De telecomprovider meldt in een e-mailbericht dat de XS4ALL-colocatiediensten per 1 november worden verzorgd door KPN. Het bedrijf meldt daarbij dat 'de colocatiedienstverlening blijft bestaan' en dat de kwaliteit daarvan ongewijzigd blijft en tegen hetzelfde tarief wordt geleverd. Met colocatiediensten kunnen gebruikers bijvoorbeeld apparatuur in een datacenter huren voor eigen gebruik. De gebruikte infrastructuur en de locatie van het XS4ALL-colocatiedatacenter blijven hetzelfde, aldus KPN. Klanten blijven 'gebruikmaken van een afsluitbare rackspace met 100mb uplink internetaansluiting en stroomvoorziening'.

Verder laat KPN weten dat het de functie voor unauthenticated smtp stopzet. Met die functie konden colocatieklanten van XS4ALL gebruikmaken van een gedeelde smtp-server voor het versturen van unauthenticated e-mailberichten. KPN stelt dat de dienst door weinig klanten wordt gebruikt. "Door de verdere integratie binnen KPN en de security-eisen stopt deze extra service op 1 november 2021", zo schrijft de provider.

XS4ALL-moederbedrijf KPN liet begin 2019 weten dat het zou stoppen met XS4ALL, maar na veel kritiek liet het bedrijf een jaar later weten dat de merknaam XS4ALL toch wel blijft, met de belofte dat klanten dezelfde dienstverlening van hetzelfde team zouden krijgen. Wel zou als onderdeel van de integratie de infrastructuur van XS4ALL samengevoegd worden met die van KPN, waaronder dus ook de colocatiediensten van XS4ALL vallen. KPN stopt per 1 oktober wel met de hostingdiensten van XS4ALL, waaronder domeinnaamregistratie, e-mail op domein en webhosting.

Reacties (83)

Hoe zit het eigenlijk met de internet klanten, is er een planning wanneer die gemigreerd worden? Want ik val ook onder die groep en als ik niks hoor ga ik gewoon weer met een jaar verlengen mits ik natuurlijk een goede deal krijg. Voor mij is dat vaste IP belangrijk, de reverse DNS voor mijn mailbak dus poort 25 moet ook open blijven.

Hiervoor is freedom.nl toch opgericht? Stuk sympathieker ook.

Zijn hier overgegaan naar freedom zodra dat kon en tot nu toe hebben ze eigenlijk oude xs4all achtige dienstverlening heel goed waargemaakt. Ben er ruim tevreden over, behalve dat KPN nog steeds geen glasvezel heeft hier.

Heb er wel een ziggo bijgenomen voor de bandbreedte/redundancy en via een pfsense VM geloadbalanced. Blijkt nogal prettig voor dit tijdperk van eindeloos online vergaderen vanaf huis. Het gebeurde net te vaak dat ik een flinke download niet wilde starten om vergaderingen van mijn betere helft niet te verstoren.

Nou Freedom is nog een stuk duurder, en die leveren TV diensten van Canal Digitaal/Online. Slechter kun je bijna niet krijgen. Zolang KPN met XS4ALL mijn abonnement niet verkloot heb ik nog geen reden om over te stappen. Doen ze dat wel dan is het vroeg genoeg om naar Freedom te gaan kijken.

Tja, tv en internet is in mijn ogen geen combinatie. Voor tv maak ik nog graag gebruik van de DVB-C diensten van de kabel-tv-opvolger.

Als je een eigen internet verbinding hebt met voldoende capaciteit, kan je altijd een internet-tv abonnement nemen bij de tv-provider van jou keuze.

Geloof me, daar ben ik meer dan jij denkt van op de hoogte. Maar ik heb graag toegang tot alles.

Dat verklaart ook je 'naam' hier op tweakers....

Ik geef zonder meer toe dat ik een paar euro meer voor een provider die dingen doet zoals Freedom dat doet over heb en TV heb ik al denk ik een decennium niet meer, dus dat kan ik lastig beoordelen.

Maar, ik zou zeggen hoe slechter de TV, hoe minder neiging ernaar te kijken, wat ik dan weer positief zou noemen.

Wij zijn het gaan doen juist ook omdat het geluiden maakt over hoe het internet hoort te werken waar ik achter sta. Dat soort vibes heb ik bepaald niet bij b.v. kpn/ziggo/etc. Ik streef ernaar om zo min mogelijk geld die kant op te sturen, bij kpn lukt dat zonder dat het al te onpraktisch wordt, bij ziggo dus helaas niet, dan vind ik fallback en onafhankelijker zijn van wat er verder in huis gebeurt belangrijker. Weet nog niet wat ik doe als er wel glas in de straat komt, 2 hele verschillende technologieen is wel tamelijk bedrijfszeker nl. Meer kans dat een van m'n houtje toutje oplossingen ergens anders in m'n lokale netwerk de zwakke schakel zal blijken.

ik heb een paar jaar lang ADSL en Kabel internet en later glas en kabel internet naast elkaar gedraaid, met name vanwege de mailbak maar eerlijk gezegd. Het viel niet te rechtvaardigen want er was praktisch nooit storing en dus heb ik de kabel internet opgezegd. Ik heb nog wel TV via de kabel.

Storings beperking is een leuke bijkomstigheid.

Het gaat mij er voornamelijk om dat als ik ineens verzin dat ik 50Gb wil DL'en, dat ik niet hoef te knijpen zodat de Teams meeting van de betere helft niet gaat haperen. Tot zover heeft de load balancer dat perfect opgelost, al zou ik juist verwachten dat ie ook wel eens verkeerd gokt welke verbinding waarvoor te pakken, is het iig nog niet merkbaar geweest. Ook is afhankelijk van het programmatje dat de download doet, knijpen niet 100% van de tijd een eenvoudige optie.

De extra snelheid is natuurlijk ook fijn, want die 109mbit die de KPN maximaal levert voor de freedom DSL begon me wat te irriteren. Ik zou natuurlijk alleen een mailaccount af kunnen nemen bij freedom, maar om heel eerlijk te zijn werd ik direkt al extreem ongelukkig van de connectbox van ziggo. Misschien als ik hem bridge oid, maar het is zo dichtgetikt dat ik daar bepaald niet vrolijk van word. Verder zijn dat vaste IP en techneuten waar ik wat mee kan bij freedom me toch ook wat waard.

De tv dienst van Canal Digitaal is nu aardig op orde. Ik stond op het punt om Canal Digitaal op te zeggen. Na de laatste update is het systeem goed bruikbaar. Mijn vrouw is grootverbruiker van opnemen en terugkijken. Dat loopt allemaal soepeltjes. Dus de opzegging is verwijderd uit mijn concepten.

Hiervoor is freedom.nl toch opgericht? Stuk sympathieker ook.

Zijn hier overgegaan naar freedom zodra dat kon en tot nu toe hebben ze eigenlijk oude xs4all achtige dienstverlening heel goed waargemaakt. Ben er ruim tevreden over, behalve dat KPN nog steeds geen glasvezel heeft hier.

Hier ook een tevreden overstapper. Wij hebben hier wel glasvezel van reggefiber, nu helaas kpn.

Als ik de freedom website bekijk vind ik het jammer dat we hier kpn-glas hebben en niet 1 van de andere leveranciers: https://freedom.nl/diensten/internet.

Hier ook een tevreden overstapper van XS4ALL naar Freedom. Je merkt dat XS4ALL aan alle kanten wordt uitgekleed. Bij Freedom werken ze hard aan een open, modern, veilig en privacy-respecterend internet. Dat vind ik erg belangrijk.

Als je je eigen mailbak hebt dan zit je toch niet vast aan poortje 25? Of gebruik je je IP thuis van buitenaf om te SMTPen?

Het is iets anders. Als je in een DHCP range zit (net als internet thuis) dan wordt je standaard op een blocklist gezet. Wat je dan doet is dat je een relay server van je provider zoekt die mail accepteert om door te sturen. Dat IP adres is een publiek servernetwerk en staat niet op de blacklist. In mailtermen : een smarthost.

Wat ze nu waarschijnlijk gaan doen is de relay server uitzetten. En dan kan je geen mail meer bezorgen op servers die die blacklists gebruiken.

Verder wat @CyBeR aangeeft : alle mail servers gebruiken poort 25 nog. Dat kan in plain text, maar de meeste servers ondersteunen ook TLS1.2 versleutelde verbindingen. Dan zou je denken dat er een Secure SMTP poort is (TCP poort 587) maar die wordt amper gebruikt omdat iedereen op 25 zit.

Dan zou je denken dat er een Secure SMTP poort is (TCP poort 587) maar die wordt amper gebruikt omdat iedereen op 25 zit.

Crypto voor email in transit hebben we nooit écht goed voor elkaar gekregen. We komen niet verder dan opportunistic encryption, dwz STARTTLS over poort 25 als het beschikbaar is. Daarbij wordt over het algemeen ook niet al te hard naar het certificaat gekeken want daar zijn eigenlijk ook geen standaarden voor binnen SMTP en het alternatief is plaintext versturen wat ongewenst is.

Als je specifieke beveiligingseisen hebt kun je meestal je MTA wel instellen om TLS + cert verification te vereisen voor specifieke hosts, maar als algemeen beleid voor email op het internet is dat niet te doen.

Poort 587 overigens, is geen secure SMTP poort maar een submission poort. Dwz, dat is de poort die je MUA (je mail client) dient te gebruiken om mail mee te versturen in plaats van 25. Daarover wordt vervolgens ook STARTTLS gedaan, maar dan wél met cert validatie. De enige secure SMTP poort is 465 (met direct TLS) maar die wordt eigenlijk bijna niet meer gebruikt.

[Reactie gewijzigd door CyBeR op 3 augustus 2021 00:37]

Er zijn wel degelijk standaarden om encryptie tussen SMTP servers te controleren en garanderen. Eigenlijk twee min of meer concurrerende standaarden: MTA-STS en DANE (in feite DANE voor SMTP).

XS4ALL gebruikt beide, voor zowel inkomende als uitgaande mail. Voor inkomend kun je dat triviaal controleren, voor uitgaand alleen handig voor DANE via havedane.net.

Het is alleen jammer dat heel veel providers die standaarden niet respecteren. De betere providers ondersteunen wel minstens 1 van deze.

Het zijn alleen geen verplichte standaarden, waardoor je nog steeds de kans loopt dat het unencrypted gebeurt. Het - in RFC Lingo - should, en niet must. Het zit niet als danig in de SMTP RFC.

XS4ALL ondersteunt een deel van RFC8689... je kunt een "RequireTLS: YES" of "RequireTLS: No" header opnemen in je bericht, om encryptie te forceren cq. niet te verplichten, tijdens afleveren.

Dat kijkt alleen niet naar de door zo goed als niemand geïmplementeerde "REQUIRETLS" SMTP extensie, want dan kun je mail nergens meer kwijt... maar je kunt wel de 1e hop na de smtp server van XS4ALL ermee garanderen (of juist DANE/MTA-STS beveiliging bewust omzeilen voor een specifieke mail).

587 (STARTTLS) en 465 (SMTP over TLS) worden gebruikt door mail clients (outlook, thunderbird, ...) om op een beveiligde manier naar de mail server te verbinden om een e-mail te verzenden.

Mail servers die onderling communiceren (mail ontvangen en verzenden) gebruiken altijd poort 25, en dat kan zowel met TLS encryptie als zonder gebeuren.

Wat dacht je van gewoon mail ontvangen via smtp op poort 25? Als ontvanger heb je geen grip op de verzendende mailservers, waarvan er een heel groot deel nog gewoon mail standaard op poort 25 aanbiedt.

waarvan er een heel groot deel nog gewoon mail standaard op poort 25 aanbiedt.

Zeg maar gerust allemaal.

ah, op die fiets ..

Dit gaat om de connectie met de smtp van xs4all, die stuurt het door naar de ontvanger, hoe die mail binnen haalt boeit dan toch niet?

Mail binnenharken via een smtp server is wel vrij lastig. Het wordt ook tijd dat niemand meer via poort 25 zonder authenticatie en versleuteling email verstuurt.

Als je je eigen mailbak hebt dan zit je toch niet vast aan poortje 25?

Wel voor binnenkomende mail van andere mailservers.

[Reactie gewijzigd door The Zep Man op 2 augustus 2021 18:26]

De colo klanten kunnen hun borst nat maken. KPN belooft al maanden dat bij het integreren van XS4ALL alles gelijk blijft. Gelijktijdig breken ze alles af.

Binnen de XS4all colo was het al merkbaar in de service, kunt niet meer zoals een jaar geleden 'even' zaalbeheer contacteren die vervolgens op een knopje duwen, een server een liefdevolle aai geven of wat woorden toefluisteren. Nu mag je geluk hebben als een verzoek binnen twee uur op de juiste plek komt. Terwijl er (nog) een deel van dezelfde toppers zitten - support requests worden door KPN anders geroute.

Ik heb mijn spulletjes al verhuisd. Maar het is jammer, het einde van een era.

Klanten blijven 'gebruikmaken van een afsluitbare rackspace met 100mb uplink internetaansluiting en stroomvoorziening'.

Die 100Mb is toch ook niet meer van deze tijd?

Wel als er een hele nette latency en goede peerings achter zitten.
M.a.w. jouw colocated server op 100mbit zou zo maar een stuk sneller/responsiever kunnen zijn voor bezoekers uit buitenland dan een server gehost op een 1000mbit thuis verbinding.

Dat is een appels-peren vergelijking. Vergelijk het met een ander datacenter in plaats van thuis en het is gewoon niet meer van deze tijd.

Het is niet helemaal toevallig dat https://dc1.amsterdam/ is opgericht.

Mooie MNOT aflevering: https://www.metnerdsomtaf...-iters-met-erik-bais.html

Laat dat nu net eens de plek zijn waar ik mijn spulletjes naar toe heb verhuisd

Ik kan me een Ibarra herinneren die beloofde dat er niets zou veranderen voor xs4all klanten, en met niets dan ook echt niets.

Ze zouden het BESTE van kpn en xs4all samen voegen.

Oud xs4all bestuur zei al, dit is niet haalbaar, daar zijn de systemen en bedrijfsstructuur van xs4all en kpn te verschillend over!!

Ziehier 2,5 jaar later.

Nou in dit bericht staat alleen dat de unauthenticated SMTP relay wordt uitgezet. Dat had XS4All al een tijdje geleden mogen doen IMHO.

Unauthenticated SMTP was bij xs4all al heel lang heel goed ingepakt:
Ja, je kan en mag unauthenticated smtp gebruiken maar:
- alleen van 'interne' netwerken. Dus als je niet vanaf een xs4all internet verbinding komt, dan niet.
- alleen met geldige header informatie zoals datum en onderwerp en dergelijke
- from: en to: adressen alleen uit gekende domeinen.

Eind vorige eeuw kon ik nog een mailtje tikken vanuit een telnet sessie naar poort 25 op de smtp server en dan in de live ingetikte mail header aangeven alsof het echt uit het begin van de jaartelling was en tussen bijbelse figuren met mail adressen zoals [e-mail] en dergelijke. Dat kan al jaren niet meer.

Er is inmiddels een aardig lijstje XS4ALL diensten toch geschrapt, ondanks die gedane toezegging.... T.a.v. je opmerking over unauthenticated smtp sluit ik me aan bij enkele eerdere opmerkingen in dit draadje: als je niet weet waarover je praat, reageer dan niet.

Ze doen het gewoon verkeerd, ze moeten eerst de xs4all dienst stoppen/aanpassen en pas later er een KPN naam aanhangen. Ook niet netjes maar dan heb je minder gezeik als er lang genoeg tussen zit.

Ik ben benieuwd hoeveel bedrijven er kapotgaan op het gebrek van unauthenticated SMTP. Veel oude (industriële/agrarische) software en apparatuur gaat uit van de simpelste vormen van de standaard. Ik heb diverse bedrijven gezien waar authenticatie op SMTP vereisen de hele bedrijfsvoering in gevaar brengt, hoe slecht die software ook is.

Laat dit een wake-up call zijn voor de mensen die nog steeds dit soort verouderde software gebruikt. Er zal vast een andere partij zijn waar die mailsystemen nog wel mee kunnen werken en van provider wisselen is een stuk goedkoper dan een nieuwe stalveegrobot kopen, maar als je bedrijf van zo'n dienst afhangt, is het echt tijd om een migratieplan op te zetten en uit te voeren. Elke keer als ik er iemand over sprak was het "ja, maar hij doet het nog gewoon dus waarom zou ik over gaan"...

Het beëindigen van de hostingdiensten is gewoon zeer jammer, zo'n grote last is webhosting nou ook weer niet en KPN heeft meer dan genoeg andere managed hostingservices die je kan afnemen bij het bedrijf. Het is de hoogste tijd om de hele XS4ALL-namespace een keer met een web archiver door te gaan voor alle links voor eeuwig op zwart gaan. Wellicht kan KPN daarmee helpen, aangezien zij weten wat er wel of niet gehost wordt?

IoT is een rampgebied. Mijn secure mailserver weigert dienst zonder STARTTLS TLSv1.2+ met forward secrecy ciphers. Je hebt nog even om ook een geldig certificaat bij een CA te regelen en daarna gaat dat ook dicht. Daarna zijn DNSSEC en DANE aan de beurt. Wat mij betreft mag dat een verplichting worden in de EU. Zodoende krijgen fabrikanten een stimulans om er iets aan te doen. Internet gekoppelde producten dienen onderhouden te worden voor de levensduur van het apparaat.

Deze stappen moeten worden genomen om te helpen email echt te beveiligen. TLS 1.2 is al weer 13 jaar geleden verschenen, dus als je het nu nog niet op orde hebt...

IoT is een rampgebied. Mijn secure mailserver weigert dienst zonder STARTTLS TLSv1.2+ met forward secrecy ciphers.

Dan host je toch lokaal op het IoT netwerk een stunnel instantie, waar de IoT apparatuur een verbinding mee maakt? Die stunnel instantie kan vervolgens het verkeer (veilig) doorsturen naar je SMTP server. Je kan zelfs stunnel (veilig) voor je laten authenticeren, voor als je IoT apparatuur dat zelf niet kan. Uiteraard moet je wel zelf voldoende beveiligingsmaatregelen treffen om ervoor te zorgen dat je stunnel instantie zelf geen open relay is (netwerksegmentering, filteren van verkeer op een eigen mailserver, etc.).

Stunnel is zo licht, dat kan je zelfs op een (OpenWRT) router draaien.

[Reactie gewijzigd door The Zep Man op 2 augustus 2021 18:39]

Dat is een beperkte workaround, het lost het onderliggende probleem niet op voor consumenten en MKB.

Feit blijft dat IoT over het algemeen slecht onderhouden wordt en dat moet nodig worden verbeterd. Met regelgeving, zodat het voor iedere fabrikant geldt en geen ervan zich eraan kan onttrekken om wat centen te besparen. Goede leveranciers vragen om dergelijke regelgeving zodat een gelijk speelveld gegarandeerd is.

Feit blijft dat IoT over het algemeen slecht onderhouden wordt en dat moet nodig worden verbeterd.

Dat wordt het niet in de nabije toekomst. Tot die tijd is het zelf goed beheren en compenseren voor de tekortkomingen.

[Reactie gewijzigd door The Zep Man op 2 augustus 2021 22:10]

Het ijzer is heet:

Rapport digitale veiligheid van iot apparatuur
Consumentenbond: veiligheidsvisie connected apparaten

Er staat ook actie op de agenda: Agentschap Telecom gaat toezicht op veiligheid IoT apparaten intensiveren

Voor een zakelijke omgeving waarin unauthenticated smtp nodig is valt intern wel een smtp-server op te zetten die deze mail verwerkt.
Als deze bedrijven groot genoeg zijn, hebben ze mogelijk al een eigen email omgeving en zou het daar rechtstreeks in kunnen.
Als er geen eigen mail omgeving is, dan adviseer ik een kleine smtp-server die naar de provider toe netjes aan authenticated smtp doet en intern de unauthenticated smtp oppakt.

Dat klinkt niet echt als een heel groot probleem, gewoon een MTA er tussen.

Lokaal kan je unauthenticated blijven werken met een relay er tussen als het moet.

Als het je eigen SMTP server is kan je dat nog grotendeels afvangen door te beperken welke IPs er naar toe mogen sturen. Zij het op de server zelf, zij het op de firewall.

En ja, hij doet het nog gewoon. Waarom zou je een machine van enkele honderdduizenden euro vervangen omdat deze op een verouderde, maar nog altijd ondersteunde manier communiceert?

Je zet dan gewoon zelf intern een smarthost op. Kan eenvoudig op Windows Server met de SMTP service.
Je configureert dan de relay restricties om connecties van het bewuste IP toe te laten (MFP, server met oude software, ...). Bij uitgaande configuratie configureer je dan een smarthost naar Office365 (smtp.office365.com) met authenticatie en encryptie op poort 587. Zorg er wel voor dat de authenticatie gebruiker Send-As of Send-On-Behalf rechten heeft op het afzender adres (of dat het afzender adres bestaat).

Ik ben benieuwd hoeveel bedrijven er kapotgaan op het gebrek van unauthenticated SMTP.

Die bedrijven verdienen het dan.... het is natuurlijk niet zo moeilijk om zelf voor een unauthenticated SMTP server te zorgen als dat echt noodzakelijk is.

Dat geld net zo goed voor jou want beweren dat er niks mis mee is slaat nergens op, unauthenticated smtp is een gigantisch cyber security risico er is van alles mis mee, als je nog oude apparatuur hebt die dit gebruikt kun je veel beter een relay gebruiken die lokaal unauthenticated omzet naar authenticated naar buiten toe.

Ik krijg een beetje het idee dat je unauthenticated verwart met open-relay. Xs4all heeft nooit een open-relay gehad (behalve misschien in de eerste dagen, toen dat nog normaal was). En als klanten er eentje hadden spoorden ze die heel snel op en werd er wat netwerk verkeer dichtgezet.

Ergens krijg ik het idee: "xs4all stopt per 1 oktober". Alleen de naam blijft bestaan.
De diensten die kpn anders biedt dan xs4all dat deed, gaan over naar de kpn-manier.
De diensten die kpn niet biedt....

Het valt mij vooral op dat de datum 'per 1 oktober' blijft. Bij de eerste berichten in mei is dat nog een 4 maanden in de toekomst. Bij dit bericht nu is het nog 2 maanden vooruit.

[Reactie gewijzigd door beerse op 2 augustus 2021 17:37]

Ergens krijg ik het idee: "xs4all stopt per 1 oktober". Alleen de naam blijft bestaan.

De naam blijft juist niet bestaan.

De naam XS4ALL blijft WEL bestaan, echter alle extra service en diensten worden volledig afgebroken door KPN. Ik ben mij ook aan het voorbereiden om het pand te verlaten.

XS4ALL-moederbedrijf KPN liet begin 2019 weten dat het zou stoppen met XS4ALL, maar na veel kritiek liet het bedrijf een jaar later weten dat de merknaam XS4ALL toch wel blijft, met de belofte dat klanten dezelfde dienstverlening van hetzelfde team zouden krijgen.
(...)
KPN stopt per 1 oktober wel met de hostingdiensten van XS4ALL, waaronder domeinnaamregistratie, e-mail op domein en webhosting.

Dat was een valse belofte. Zo stoppen ze ook met de dienst om voor een geleverde internetverbinding een extra pakket IPv4 adressen af te nemen, wat ook een onderdeel was van hun dienstverlening.

Voor mij was dat een reden om van een verbinding in mijn beheer het jaarcontract open te breken, en vanaf 1 oktober over te gaan om een andere provider.

[Reactie gewijzigd door The Zep Man op 2 augustus 2021 19:45]

Veel reacties lijken het verschil tussen unauthenticated smtp en anoniem mailen niet goed te zien.

Wat XS4ALL aanbiedt (tot 1 oktober) met die dienst, is een mogelijkheid om alleen op basis van je IP adres via smtp mail te versturen. Het dient daarbij dus als "simpele MTA" naar de buitenwereld, precies de dienst waarvan veel mensen zeggen "draai dat gewoon zelf". En dat kun je wel zeggen, maar dat is niet zo triviaal. Bij XS4ALL wordt er bijvoorbeeld per IP wel degelijk rate limiting, spam/virus filtering, etc toegepast. En de uitgaande hosts zijn al bekend bij grote ontvangers, zodat de kans dat het door komt, groot is.

En zodra er te veel troep vanaf een IP adres komt (bv vanwege een gehackte/geinfecteerde host), dan wordt die automatisch geblokkeerd, zonder de rest van de hosts te blokkeren. En XS4ALL security kan via het IP adres precies nagaan wie die colo klant is, en contact opnemen.

En dat IP adres staat ook gewoon in de Received: header, dus alle ontvangers kunnen ook zien waar het vandaan komt, en op basis daarvan eventueel zelf spamfiltering toepassen. (Als je via smtp authenticated mail stuurt, wordt je verzendende IP weggehaald. Privacy dingetjes. Tenminste, bij XS4ALL...)

Je kunt via je colo machines straks uiteraard nog wel authenticated mail sturen, maar dat kan vanaf de hele wereld in feite. Je zit dan alleen wel vast aan de wat beperktere limieten voor persoonlijk email gebruik, grote mailings sturen vanaf je colo machine is er dan (op die manier) niet meer bij.

Volgens de provider blijft de dienst grotendeels hetzelfde, hoewel het bedrijf wel een smtp-functie schrapt.

Al een derde functionaliteit die wordt geschrapt na de dichtere integratie van KPN en XS4ALL. Er zal écht, eerlijk waar, niets veranderen in de functionaliteiten voor klanten hoor!

Ik vind dit altijd zo'n dooddoener altijd. Je kunt niet alles hetzelfde houden. We rijden toch ook niet meer op een paard? Ik geef KPN groot gelijk in deze. Je hebt helemaal geen relay nodig. Ga lekker zelf MTAtje spelen?

Ja, zelf mtatje spelen. Vooral mensen die een dienst afnemen lekker laten knutselen zonder dat ze er verstand van hebben, wat kan er nou mis gaan met mail? Verder, stel dat er 100 gebruikers waren, dan moeten er ipv 2 opeens 200 (redundantie) servers moeten draaien voor deze simpele taak. Zonde van de resources als je het mij vraagt.

Het gaat me hier niet om de service, maat het principe. Er werd toendertijd expliciet vermeld dat het samenvoegen geen andere effecten had dan dat KPN nu ook van XS4ALL technologieën gebruik ging maken en dat de naam op het factuur zou veranderen.

Ondertussen zijn we 3 services verder die niet worden aangeboden zoals dat onder XS4ALL werd gedaan, hetzij door het te schrappen zoals nu het geval is, of door het niet meer voor consumenten aan te bieden.

Het had net zo goed iets anders kunnen zijn dan unauthenticated SMTP, feit is dat KPN al de derde keer een belofte breekt.

Maar wanneer stop je dan ‘met alles hetzelfde houden’? Is dat een periode van 5 jaar bijvoorbeeld?

Ik vind het best logisch dat je als bedrijf bepaalde keuzes maakt en het momentum aangrijpt om diensten die al verouderd/onveiliger zijn af te schalen.

Maar wanneer stop je dan ‘met alles hetzelfde houden’? Is dat een periode van 5 jaar bijvoorbeeld?

Goede vraag, in ieder geval niet terwijl je nog bezig bent met de diensten daadwerkelijk naar jezelf over te hevelen.

Dat er nooit iets ging veranderen voor xs4all klanten (of personeel) geloofde natuurlijk niemand.

Toch is KPN voorzichtiger in hun aanpassingen dan ik had verwacht. Kleine stapjes tegelijk, en niet al te snel. De luide protesten rond de overname zal ze geleerd hebben wat een sterk merk ze in handen hadden.

Uiteindelijk zal er van xs4all alleen dat merk overblijven, zo zit corporate logica nou eenmaal in elkaar.

Ben eigenlijk wel benieuwd of dit niet gewoon op de planning stond bij XS4ALL, en misschien al voordat KPN besloot de boel te absorberen. Niet dat ze een al datum hadden maar eerder iets als we gaan dit doen voor 2025 of 2030.

Uiteraard kan dat alsnog dan op laste van het moederbedrijf 'besloten' zijn.

[Reactie gewijzigd door Amorac op 3 augustus 2021 09:12]

Nope, niet voor colo.

Dus als XS4ALL er zelf (terecht) mee gestopt zou zijn is er vuiltje aan de lucht?
Kom op, je kunt ook van een mug een olifant maken.

Heb je meer dan de eerste zin gelezen? Als KPN niet die belofte had gedaan was het anders geweest. Dat hebben ze echter wel gedaan, en is het ook nog eens naar elke klant gestuurd. Maar ondertussen wel diezelfde belofte meermaals breken, dan hadden ze dat gewoon nooit moeten zeggen.

Ja, want XS4ALL heeft nog nooit in haar bestaan een dienst gewijzigd op gestopt.. Natuurlijk wel. Maar nu diensten over gaan naar KPN zouden ze ineens niets meer mogen wijzigen of mogen stoppen?

Ik vind dit een gevalletje zeuren om het zeuren.

Unauthenticated smtp is gewoon niet meer van deze tijd, security-wise.

Het gaat me niet om het feit dat er iets gestopt wordt, het gaat me er niet om wat er gestopt wordt, het gaat me er om dat een belofte aan klanten drie keer is verbroken door KPN. Ze hadden die belofte niet hoeven doen, maar in plaats daarvan kozen ze er wel voor om de mensen zo rustig mogelijk te houden.

Het is niet zeuren om zeuren, het is zeuren om een schriftelijke overeenkomst die verbroken wordt.

Ik vind dit altijd zo'n dooddoener altijd. Je kunt niet alles hetzelfde houden. We rijden toch ook niet meer op een paard? Ik geef KPN groot gelijk in deze. Je hebt helemaal geen relay nodig. Ga lekker zelf MTAtje spelen?

Beloof het dat niet. Blaas al helemaal niet heel hoog van de toren dat er voor de klanten niets veranderd.

Belofte maakt schuld, en bij het type klant dat xs4all bediend, is dat een hele grote schuld.

Zeg als je nou normaal doet dan heb je misschien kans dat iemand een leuk gesprek met je aan gaat. Dit is nu al de 3e reactie waarin je enige argument het op de man uitschelden is. (Die terecht gemint wordt)

100mb uplink internetaansluiting

!? Wat een achterhaald product dan?

Offtopic, maar misschien niet helemaal, aangezien nog een dienst wordt gestopt binnenkort.

Blijkbaar is dit niet het enige wat KPN gaat stoppen bij XS4all. Net mijn internet opgezegd met behoud van Pack en Bellen, krijg ik te horen dat deze combinatie vanaf 1 november aanstaande ook niet meer mogelijk is.

Dus alleen Pack met Bellen is NIET meer mogelijk vanaf 1 november aanstaande.