Dat impliceert dat KPN aparte netwerksegmenten aanhoudt voor verschillende categorieën klanten, hetgeen ik in mijn openingsbericht eveneens aangaf te vermoeden maar volgens anderen geenszins het geval is. Het probleem raakt dus ook zakelijke klanten en zo kijkend op internet heeft KPN de mogelijkheid om te emailen wel vaker gesaboteerd in haar obsessie om nanny te willen spelen.

Mocht je het interessant vinden deel ik graag voor een tweede keer de huisregels. 

Wacht nou eens een reactie van een moderator af voor je weer met “ambtenaren, nanny spelen”, en andere teksten komt.

Dan wijs ik jou even op dit topic  :

Hier zie je hoe het er gebruikelijk aan toe gaat op dit forum. Iemand met de status van moderator mengt zich in een onderwerp met de meest stompzinnige reactie mogelijk en misbruikt zijn status als moderator vervolgens om zijn reactie als “beste antwoord” te markeren ten behoeve van zijn eigen ego.

Zullen we ‘m even doorlopen?

• heeft dat domein een uitgaande server?
    → Ja, “server@v-n-s.nl” zoals de klant in zijn opening meldt
• als dat zo is…
    → nog steeds ja, dat is zo
• dan kan je die instellen om emails te versturen
    → ja dat kan inderdaad en dat heeft de klant ook zo ingesteld
• als dat niet zo is…
    → het is dus wel zo
• kan je een mail sturen naar abuse@kpn.com
    → terwijl je dus geen email kan versturen omdat KPN de verzending blokkeert

Diepe zucht inderdaad. Merk ook op dat het betreffende account 0 reacties aangeeft, dus je kan er gif op innemen dat deze ga maar rustig uit van voormalige klant naar het forum is verwezen door het callcentrum dat intern had kunnen verifiëren of deze klant wellicht om een of andere reden op een blacklist was geplaatst. kastje muur.

Zie dan ook de opmerking van @JanD dat de afdeling die dit proefballonnetje heeft opgelaten zonder zelfs ook maar het callcentrum van deze wijziging in kennis te stellen z.s.m. aan de slag gaat met het aanpassen van de helptekst op de webpagina. Nou we weten zo ongeveer al wat er in komt te staan en er zijn ook al meerdere meldingen dat het inloggen dus niet werkt.

En nogmaals, inloggen impliceert dat de KPN email server de verbinding beschouwt als komende van een interne client en de inloggevens gebruikt om een nieuwe envelope aan te maken. De email is dan niet meer afkomstig van me@domein.nl maar van account@kpnmail.nl en dat betekent dat als er een DKIM handtekening in de email staat deze is gecorrumpeerd en de email verderop in de keten geblokkeerd zal gaan worden. Anders gezegd, hier staat echt totale onkunde en wanprestatie bij KPN in de basis.

Oh en trouwens als jij woorden als ambtenaar en nanny als beledigingen opvat en iemand die stelt ambtenaar te zijn noemt het als een belediging te beschouwen vergeleken te worden met KPN beleidsmedewerkers, dan is mijn beeld van deze mensen hier in dit topic zelfs nog de meest positieve te noemen.

Ik heb al jaren een eigen mailserver en hier werkt alles prima. Net als jij ben ik een klant, ik wil je graag proberen te helpen maar het wordt uit jouw berichten niet duidelijk wat je hebt geprobeerd. 

Vroeger was het inderdaad noodzakelijk om inkomende en uitgaande mail te laten lopen via de servers van KPN, kan me nog een constructie herinneren waarbij je 2 mx records met verschillende prioriteit moest aanmaken om inkomend bereikbaar te  zijn. Dit hoeft gelukkig al lang niet meer.

Ik heb mijn eigen mailserver ingesteld op direct versturen op basis van mx records. En dit werkt al jaren prima. Dit is de instelling die ik ook zou aanbevelen omdat je dan ook je dmarc en spf records goed kan instellen.

Heb net nog even getest als ik de mail relay via smtp.kpnmail.nl verstuur en ik de gebruikersnaam en wachtwoord van mijn kpnmailbox gebruik.  Mail wordt dan ook prima verstuurd en zonder dat de naam van de verzender wordt aangepast. 

Kan je aangeven hoe je mailserver stond ingesteld voor de verhuizing en wat je tot nu toe geprobeerd hebt?

Jezus, meen je dat nou?

Die bizarre constructie met de MX records om de KPN server als fake secundary in te stellen voor je domein had ik hierboven al uitgelegd. Ik herinner me dat toen dat eraf ging ik nog even heb geprobeerd of de blokkade op poort 25 uitgaand eveneens was verwijderd. Dat bleek toen niet het geval en ik heb nooit meer enige aanleiding gezien om dat later nog eens te proberen. Het is immers weinig zinvol om iets te repareren dat niet stuk is. Het blijkt nu dus mogelijk om connecties naar poort 25 buiten het KPN netwerk te maken en als ik jou goed begrijp is dat al enkele jaren zo.

Ik heb momenteel als overbrugging mijn SPF aangepast zodat ik via de VPN van mijn werk de uitgaande server daar kan misbruiken voor mijn eigen domein, maar dat is natuurlijk een minstens zo lelijke “oplossing” als dat gepruts voorheen om überhaupt email te kunnen ontvangen.

Vraagje nog inzake deze opmerking:

Heb je dan gekeken naar de headers in de email of (en dit vereist toegang tot de server logs of een spamfilter op SMTP niveau die deze informatie aan de headers toevoegt) naar de envelope? Ik sla namelijk toch wel aan op dat kpnmailbox waarmee jij aangeeft dat de relay jouw credentials accepteert en de mail naar buiten stuurt. Mijn KPN inlog is echter niet gekoppeld aan een kpnmailbox en dat lijkt bij de andere genoemde case eveneens het geval te zijn (even vanuit het geheugen een Planet account en die ander weet ik niet meer). Ik ben er op dit moment eigenlijk volledig zeker van dat de KPN mailserver niet meer als relay fungeert maar uitsluitend nog als mailserver voor kpnmail accounts. Ik ben er ook van overtuigd dat dit zich op termijn zal bewijzen doordat gebruikers die het nu dan voor elkaar krijgen middels de foute informatie die KPN hierover op de website verstrekt hun emails toch weer gebounced gaan krijgen omdat ze “fake” afzender adressen in hun emails plaatsen.

Goedemorgen @gordonb3 en bedankt voor jouw bericht.

Wat @EAZ1964 zegt, klopt helemaal; eigen mailservers ondersteunen we niet (wel bij zakelijk).

Dat is een hele goed tip die wordt gegeven door @eagle3824 en hopelijk heb je daar iets aan gehad. 

Opvolging:

Ik ben nog steeds aan het uitpakken en kwam gisteren toevallig een oude KPN installatiekaart tegen met daarop nog net leesbaar in vervaagde pen iets van een kpnmail account. Ik heb de hele boel omgebouwd met nu Postfix als externe mailer (was de send port van een Perl gebaseerd spam filter) en met SASL kreeg ik een verbindingsfout. Vervolgens geprobeerd met StartTLS en deze keer een fout dat KPN kennelijk verouderde SSL protocollen gebruikt waardoor ik moest terugschakelen. Met lager beveiligingsniveau vervolgens opnieuw de melding dat ik dien te autoriseren. Uiteindelijk nog met onversleuteld geprobeerd (lekker veilig hoor) en nog steeds dezelfde autorisatie fout. Misschien had ik gewoon eerst moeten proberen of ik met dit account kon aanmelden op ‘Mijn KPN’, want dat bleek dus eveneens niet te werken dus kennelijk heeft KPN dit al jaren ongebruikte account ergens een keer gewist. Bottom line: de toegang tot deze server is mij volledig ontzegd want alle genoemde pogingen herhaald met mijn werkende KPN inlog blijven mij de autorisatie fout opleveren.

Ergo het is voor mij niet mogelijk om te verifiëren wat het inloggen doet met de email envelope, maar ik ben er desondanks voor 99,99% zeker van dat de KPN server deze vervangt en dat dientengevolge email bounces afhankelijk van op welk niveau deze plaatsvinden terecht gaan komen in de kpnmailbox in plaats van bij de oorspronkelijke verzender.

De standaard instelling van Postfix zonder relay werkt nu inderdaad zoals het behoort en jaren geleden ook gedaan had moeten hebben. Dank voor de info derhalve, maar deze had ik uiteraard gewoon van KPN moeten krijgen. Jaren geleden zelfs al, maar het enige dat ik van KPN terugkrijg is dus hetzelfde nikszeggende gezanik als van de duizendplussers in dit draadje dat ik iets zou doen dat niet conform de protocollen voor particulieren zou zijn. Ik wordt daar nogal kriegel van.

Dat is een kwestie van opinie. Ik zie hier de 26e off-topic bijdrage gevuld met desinformatie welke jij hier ook nog eens herhaalt. Ter verduidelijking, tenzij er sprake is van aparte netwerksegmenten voor zakelijk en “particulier”, hetgeen zoals iemand hier verklaarde niet het geval zou zijn, bestaat het enige verschil uit het verstrekte modem en ik kan uit ervaring vertellen dat KPN inderdaad de onhebbelijke gewoonte heeft om met enige regelmaat via de backdoor in de Experiabox de firewall instellingen te overschrijven. Daar bestaat een heel simpele oplossing voor, gewoon een ander modem gebruiken.

Dit was zo’n beetje de eerste on-topic bijdrage en de informatie die hierin wordt verstrekt is werkelijk om steil van achterover te vallen. Wat hier namelijk staat is dat als ik een nieuwe klant was geweest dat ik dan nooit met dit probleem geconfronteerd zou zijn geweest. Dit is namelijk hoe je het normaal gesproken zou instellen. De reden dat ik juist wel tegen dit probleem aanliep is omdat KPN in het verleden op dit verkeer een blokkade had ingesteld en voorschreef dat dit verkeer via de KPN servers moest lopen. En die servers heeft KPN dus nu onlangs voor deze toepassing gesloopt.

Dus als we de ruis weglaten van dat ik als gevolg van de ambtelijke opstelling van KPN vermijdbaar een maand offline  ben geweest en daar flink ongemak en kosten aan heb gehad, alsmede dat ik op basis van foutieve informatie in een nieuw contract ben gemoffeld waar ik van af wens te zien en daar ook wettelijk in gerechtigd ben maar zo ongeveer dezelfde flauwekul op terugkrijg, dan is de essentie van deze klacht als volgt:

• Dat KPN haar klanten onjuist informeert of op z’n best totaal niet. En dat is onacceptabel.
• Aanvullend dat KPN zichzelf onbereikbaar maakt. Dat er hierbij gebruik wordt gemaakt van een callcentrum is tot daar aan toe, maar wanneer je als bedrijf je gebruikers met een probleem dat jij dient op te lossen naar een gebruikersforum stuurt kan je ze beter meteen het nummer van de concurrent geven.

Hoi @gordonb3 en dank voor jouw reply.

Je hebt een vast abonnement van ons. Dus heb je ook een kpn e-mailadres (of meerdere). Een van deze moet je gebruiken om te autoriseren bij de smtp server.

Je kunt controleren welke mailadressen je hebt door in te loggen op email.kpn.com. Log in met je KPN ID. Je krijgt dan een overzicht van alle adressen. Klik er een aan, dan kun je het wachtwoord ervan wijzigen (als je deze niet meer weet). Gebruik dan dit mailadres en het bijbehorende wachtwoord voor de smtp server.

Hoi Jan,

Op dit moment is echt de enige reden waarom ik nog in staat zou willen zijn om via deze weg email te kunnen versturen om op een door mijzelf beheerde email server te verifiëren welk afzender adres de KPN smtp server doorgeeft. De aanmerking dat er echt met een “kpn e-mailadres” ingelogd dient te worden en dus niet met een regulier account maakt het feitelijk alleen maar nog overbodiger om nog te willen verifiëren dat via deze route de DMARC van de oorspronkelijke server overschreven en voor zover dat onvolledig gebeurt dus ook ongeldig wordt gemaakt.

Het zou KPN sieren wanneer zij gebruikers van de oorspronkelijke relay, waarvan zij dus via de logs weten wie dat zijn omdat dit de gehele opzet was van de vroegere verplichting, correct te informeren dat deze verplichting reeds jaren geleden is komen te vervallen en dat zij hun email server overeenkomstig de default settings regulier als smarthost dienen in te stellen.

Hoi @gordonb3 ,

Ik heb het topic even doorgelezen, en het wordt er allemaal niet duidelijker van wat nu precies het concrete probleem is. Daarbij zie ik ook diverse aannames die simpelweg niet kloppen.

Ik begrijp dat je je mailserver zo in wil stellen dat deze of gebruik maakt van de smtp server van je hoster, of je je mail rechtstreeks uit wil sturen. Kun je kort en bondig uitleggen tegen welke problemen je hierbij aanloopt en welke foutmeldingen je precies krijgt? (en dat dus beperkt tot de problemen waar je daadwerkelijk tegenaan loopt en niet problemen waarvan je aanneemt er tegenaan te gaan lopen)

Binnen het KPN netwerk wordt niets geblokkeerd, ook poort 25 niet. Dat is misschien al wel meer dan 15 jaar geleden opgeheven en destijds hebben we klanten daarover geinformeerd. Wat je wil zou dus prima moeten kunnen.

Lekker binnenkomen met meteen al een onjuiste bewering. Ik ben 12 jaar geleden overgestapt van Ziggo naar KPN vanwege aanvullende eisen aan mijn internetverbinding waar KPN wel aan voldeed en Ziggo niet. Ik zal niet vragen of er enige voorstelling bestaat bij het ontdekken dat met praktisch een kopie van een werkende email server op het werk het vanaf een thuis geplaatste machine binnen het KPN netwerk niet mogelijk bleek om emails te versturen EN te ontvangen. De standaard respons is hier immers "dat ondersteunen wij niet voor particuliere klanten”.

Vermoedelijk doel je op de kennisgeving van 2 juli 2015, dat is dus amper meer dan acht jaar geleden. Ik heb even in de toenmalige emailwisseling met de klantenservice zitten graven en het blijkt niet helemaal gegaan te zijn zoals ik het me herinner. Poort 25 bleek weliswaar in beide richtingen opengesteld te zijn zoals de kennisgeving vermeldde, maar verstuurde emails bleken door grote email providers geblokkeerd te worden op basis van een of andere blacklist waardoor het alsnog noodzakelijk bleek om de relay te blijven gebruiken. Nota bene mijn emails naar KPN zelf kwamen zelfs uitsluitend aan wanneer ik deze via de relay verstuurde. Tegenwoordig is dat allemaal een stuk makkelijker geregeld met SPF, maar dat was toen nog een “proposed standard”. Ik zal verder niet teveel uitweiden over de communicatie, maar een van de “tips” die ik kreeg was dat ik het eerste MX record moest verwijderen (dus alleen die naar de KPN relay laten staan) en dan zou het allemaal gaan werken zoals bedoeld. Ik ga ook geen vragen beantwoorden wat hier fout aan is.

Had ik mezelf de communicatie van die tijd tot op de letter moeten herinneren en dientengevolge weten hoe het nieuwe probleem nu opgelost moest worden? Jij denkt nota bene dat het meer dan 15 jaar geleden zou zijn en hebt er dus al helemaal geen actieve herinnering aan. Het grote probleem hier is dat KPN een meester is in ontzettend foute timing. Poort 25 openzetten terwijl KPN nota bene zelf early adopter is van een nieuwe DNS gebaseerde antispam maatregel en dan niet in staat zijn om klanten die daar tegenaan lopen te informeren dat (en vooral ook hoe!) ze hun DNS moeten aanpassen. Ik maak mezelf sterk dat dit nog steeds nergens op enige KPN site te vinden is maar ik laat mezelf op dit punt graag in het ongelijk gesteld zien.

Nee deze keer had KPN het niet zelf in de hand (ondanks wel te voorkomen), een fysiek nieuwe verbinding, een gewijzigde overeenkomst, en tussen het moment van afsluiten van de oude verbinding en het tot stand komen van de nieuwe verbinding de relay permanent onbruikbaar maken. Achteraf gezien had ik wellicht wat minder met gestrekt been erin kunnen gaan, maar de totale nonsens die ik hier vervolgens over mij heen gestort kreeg verbetert mijn beeld over KPN allesbehalve.

Een paar zaken:

1. Het is nog steeds niet duidelijk wat je probleem is. Als je geholpen wil worden, is het handig een concrete probleem omschrijving te geven. Zonder dat kunnen wij niets doen.
2. RFC7208 is op een zelfde manier een proposed standard als RFC822 dat is. Het lost tevens geen blacklist problemen op, dit heeft dus niets te maken eventuele blacklist problemen
3. Je kan jezelf delisten van de PBL, de blacklist waar je het over hebt.

Als je daadwerkelijk geholpen wil worden horen we het graag, uiteraard, maar als je enkel maar boze rants wil plaatsen kunnen we niet veel meer doen.

Ik heb geen idee hoe hopeloos complex jullie dit in jullie hoofd proberen te maken en wat jullie er allemaal omheen aan het verzinnen zijn. Nogmaals:

• Ik heb een werkend email systeem van de ene KPN aansluiting naar een andere KPN aansluiting verplaatst en vervolgens kreeg ik alle emails terug. Punt. Niks meer, niks minder.

Aanvullend ben ik stevig over de rooien dat ik honderden euro’s (zo niet meer) schade heb ondervonden doordat KPN mij een maand lang niet de overeengekomen dienst heeft geleverd, hetgeen te voorkomen was geweest wanneer KPN niet zo halsstarrig aan haar ambtenarenverleden vast zou houden. Dus ja ik hap op elk trollbericht dat jullie plaatsen. Grappig hè?

Er ontbreekt nog steeds concrete informatie.  Dat je geen mail meer kan versturen vanaf je eigen domein was duidelijk, dat is echter het enige wat duidelijk is.

Welke uitgaande mailserver wil je gebruiken.

Welke foutmelding(en) krijg je.

Overige relevante informatie, met de nadruk op relevant.

Deze informatie mist (bijna) allemaal in je eerdere berichten of staat verstopt tussen alinea's vol met aannames en andere voor dit probleem niet relevante informatie.

Mijn. Staat er al zeker twintig keer. Evenals dat ik dat al ruim tien jaar zo doe.

Geen. Ik krijg de email gebounced met 550 Authorisatie vereist. Staat er ook al zeker twintig keer.

Blijf je nou trollen, of ga je een keertje serieus lezen?

Hoi @gordonb3 ,

Zoals al meerdere keren aangegeven willen we graag helpen om je probleem op te lossen, maar je houding staat hierin nogal enorm in de weg. Ik wil je er voor de laatste keer even op wijzen dat als je geholpen wil worden, je wel in een meewerkende modus zal moeten gaan. Hierbij verwijs ik ook even naar onze algemene voorwaarden die aangeven dat in geval van storingen of problemen je medewerking verplicht is in het oplossen ervan, en dat bij de communicatie in het oplossen ervan ook gewoon respectvol gecommuniceerd wordt. Mocht er niet per direct iets veranderen aan de manier waarop je hier op posts reageert, dan zullen we niet langer tijd besteden aan het meedenken voor een oplossing.

Als je jouw eigen mailserver gebruikt, zonder hierbij een extra uitgaande relay te gebruiken, en er komt een foutmelding of een bounce die aangeeft dat er authorisatie vereist is, dan komt die foutmelding dus van je eigen mailserver. Kun je eens zo'n volledige melding copy/pasten (of een screenshot ervan plaatsen)?

(Inderdaad. @Raymondt heeft gelijk. De toon waarop @gordonb3 antwoordt, zorgt er niet voor dat er een “goede sfeer aanwezig is” in dit topic.)

Suggestie:

Stuur weer een email (die ge-bounced wordt).

Vul jouw profiel hier op het forum volledig in en vermeld bij “Opmerkingen” gegevens van jouw relay server (bijv. naam en emailadres van de server en het IP adres van de emailserver). Hopelijk kan dan bijv. @Raymondt met bovenstaande gegevens eens in de systemen van de KPN kijken en zien wat er aan de hand is.

Als je helemaal geen bounce mededeling (van de KPN of van jouw hostingprovider ) krijgt dan lijkt het erop dat jouw emails niet eens de KPN emailservers heeft bereikt.

Die “toon” is dus het gevolg van het feit dat in dit hele topic slechts één persoon een reactie heeft geplaatst welke relatie heeft met het onderwerp. De rest is een stapel flauwekul van enerzijds mensen die kennelijk van mening zijn dat ik mijn internetverbinding uitsluitend zou mogen gebruiken om een beetje te facebooken terwijl sinds corona thuiswerken eerder de norm is geworden dan iets bijzonders en anderzijds van mensen die kennelijk moeite hebben met de Nederlandse taal dat wanneer gesteld wordt dat iets niet *meer* werkt dat dit dan impliceert dat het eerder *wel* werkte.

Ik ben hier nu even kwijt hoe vaak ik nu al verteld heb dat de enige wijziging(en) in mijn situatie aan de KPN zijde van het modem heeft plaatsgevonden maar je ziet hier nu dus die gasten van de afdeling volharden in het standpunt dat alles dat zij doen volledig doordacht zou zijn en zonder consequenties voor gebruikers. Ik heb luttele berichten hierboven gevraagd om een link op de KPN site waar klanten wordt uitgelegd hoe zij correct een eigen mailserver kunnen inrichten, heb jij daar een reactie op gezien? Ik in ieder geval niet.

In twaalf jaar tijd heb ik KPN uitsluitend bezig gezien om het gebruik van eigen mailservers te bombarderen. De truc om email te kunnen ontvangen toen poort 25 inkomend werd geblokkeerd? Niet via een KPN pagina maar een extern forum. In 2015 zette KPN dan de poort open, maar zoals achteraf bleek niet nadat zij eerst de klantensegmenten had aangemeld als “untrusted sender” bij onder andere Google en Microsoft en zonder klanten te informeren via welk DNS record zij deze status ongedaan konden maken. Reactie van KPN in die tijd was om mezelf van de PBL lijst te laten verwijderen, maar die gaven aan dat ik daar helemaal niet geregistreerd stond. Zoals in voorgaande alinea duidelijk gemaakt verstrekt KPN deze informatie nu acht jaar later nog steeds niet. Als extra info, op mijn zakelijke aansluiting in het datacentrum werd ik twee jaar later pas met SPF geconfronteerd en ook netjes vooraf daarover geïnformeerd door de netbeheerder. Wat hier hoofdzakelijk frustreert is de bulk aan desinformatie vanuit KPN. Je ziet het hierboven bijvoorbeeld met opnieuw de verwijzing naar PBL onder het motto van ga daar maar klagen want dan zijn wij van jou af. Klantgerichtheid nul, het idee dat jouw houding klanten kan wegjagen en als gevolg jouw eigen baan op de tocht zetten, totaal niet aanwezig. En waarom zou je ook? Er is toch geen hond die ooit kan achterhalen wie achter noreply@ zit en anders is het wel de schuld van die bijklussende student op het externe callcentrum.

Goedemorgen @gordonb3 en meelezers,

Die toon komt niet door de reacties in dit topic, want die toon zit er al sinds het eerste bericht in, toen er dus nog geen reacties waren.

Je was jezelf er al van bewust: dat had inderdaad gekund en zeker na meermaals het verzoek om op jouw houding en toon te letten en meermaals het aanbod om op jouw verder te helpen. Met de summiere informatie die je tot nu toe gegeven hebt, lukt het met alle liefde in de wereld niet om je verder te helpen. En juist ‘die gasten van de afdeling’ ( @Raymondt en @Dennis ABD ) kunnen je met de juiste medewerking en informatie verder helpen: jammer dat het nu niet lukt! 
 

Een link op de KPN site waar klanten uitgelegd wordt hoe zij een mailserver in kunnen richten is er niet, en die komt er ook niet. Ten eerste ondersteunt KPN dit niet, en ten tweede is het zo dat zij die de technische kennis hebben om een mailserver in te richten, ook de technische kennis wel hebben deze op een juiste manier met het internet te verbinden. Daar komt ook bij dat het zelf in dienst hebben van een mailserver een bepaalde verantwoordelijkheid met zich meeneemt (niet in de laatste plaats om er bijvoorbeeld voor te zorgen dat ie voldoende beveiligd is tegen spammers. Wanneer een mailserver op een thuisverbinding per ongeluk een open relay wordt, kan dit leiden tot directe afsluiting van de gehele verbinding).

Met dit soort berichten en het uitblijven van antwoorden / aanvullende informatie, komen we niet verder en daarom gaat dit topic op slot.
We, en dan spreek ik namens het Forum team en Raymondt en Dennis, concentreren ons vanaf nu liever op andere klanten die wel willen meewerken aan een oplossing. 

Ik hoop uiteraard dat het lukt om jouw mailserver alsnog werkend te krijgen!