Hi @MarcoCaspers, dank voor je bericht en reactie! Ik denk graag met je mee. Kan je mij vertellen welke e-mailservice je gebruikt om de mail te bekijken? Heb je deze gekoppeld aan bijvoorbeeld een Outlook? Mocht je in de mogelijkheid zijn om de instellingen met ons te delen, graag. We horen het graag! 

Hallo Boris,

Bedankt voor je reactie.

Ik heb geen “service” nodig om e-mail te lezen.

Zoals je in het artikel kunt lezen heeft T-Mobilethuis outbound SMTP (TCP poort 25) geblokkeerd.

Dit betekend dat je geen e-mail kunt verzenden. Het heeft dus niets te maken met het lezen van e-mail (In ieder geval, niet het lezen door mijzelf).

Ontvangen gaat prima. De combinatie die ik hiervoor gebruik is Postfix voor ESMTP/SASL, Dovecot voor IMAP/POP3 en ik gebruik een Let's Encrypt wildcard certificate voor TLS encryptie.

In principe eender welke e-mail client die IMAP en/of POP3 ondersteund is te gebruiken.

Gebruik maken van een SMTP relay is helaas een van de weinige opties 

 om “normaal” e-mail verkeer te kunnen verzenden.

Het probleem is dat bij een relay je effectief een man-in-the-middle hebt die fijn kan meelezen met alles wat je verzend via die relay.

Of die relay nu T-MobileThuis heet of Sendgrid zoals in het gelinkte artikel maakt daarbij niets uit. Ik zou echter liever gebruik maken van mijn eigen ISP dan van een derde partij aan de andere kant van de wereld waar ik er vrij zeker van kan zijn dat mijn e-mails worden meegelezen.

Niet dat er iets schokkends in staat dat geheim is of iets dergelijks, maar het principe..

Voor wat betreft de configuratie, het lijkt erop dat de server configuratie die JacobK in het artikel op 31 oktober vorig jaar plaatste niet meer functioneerd.

Ik heb effectief een copy paste gedaan van die configuratie, met natuurlijk de aanpassing naar mijn situatie m.b.t de inhoud van de sasl_passwd file.

Voor zover ik van buitenaf kan nagaan, aan de hand van debug logging, lijkt het erop dat genoemde server relay verkeer actief blokkeert.

Het enige dat ik nog niet gedaan heb is een packetsniff.

Maar eerlijk gezegd was ik het gisteren zat en had er geen zin meer in. Ik heb het werkend met Sendgrid, maar zoals gezegd ben ik daar niet zo happy mee. Ik beleg liever mijn netwerk verkeer bij mijn ISP i.p.v. bij een derde partij aan de andere kant van de wereld.

Niet dat T-MobileThuis niet mee zou kunnen kijken, maar toch.

Een andere oplossing waar ik aan heb zitten denken is het gebruik maken van IPv6.

T-Mobilethuis kan hier niets mee aanvangen (vooralsnog). Ik heb een eigen /64 blok aan ip adressen via een tunnelbroker. Dmv een IPv6 over IPv4 tunnel zou ik gewoon SMTP outbound kunnen doen. zodat het echtstreeks, via een encrypted TLS verbinding op de server wordt afgeleverd. Het probleem is dan alleen dat ik dan alleen mail servers die via IPv6 bereikbaar zijn kan benaderen. En hoewel IPv6 al bijna 25 jaar oud is, is het gebruik hiervan helaas bij heel veel mensen nog niet doorgedrongen, waardoor die effectief niet bereikbaar zouden zijn.

Dus het werkt wel, maar niet helemaal.

Mvg,

Marco.

De SMTP relay werkt niet meer met TLS: 

Dit is de error: 

SSL_connect error to smtp.t-mobilethuis.nln37.143.82.162]:587: -1
Jun  2 13:23:53 media postfix/smtpm105672]: C928543BBB: to=<xxxx@gmail.com>, relay=smtp.t-mobilethuis.nl.37.143.82.162]:587, delay=990, delays=990/0.05/0.02/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure)

Dit betekend dat smtp.t-mobilethuis.nl op port 587 geen encryptie ondersteund terwijl ze dit wel doen volgens de website: 
https://www.t-mobile.nl/klantenservice/thuis/internet-wifi/email-instellingen

de server: smtp.t-mobilethuis.nl ondersteund dus geen encryptie meer (Dit werkte voorheen wel). 
En zou volgens de handleiding nog steeds moeten werken. 

Uit t feit dat poort 587 een TLS error geeft op host: smtp.t-mobilethuis.nl concludeer ik dat t-mobile Proxy naar smtp.glasoperator.nl verkeerd geconfigureerd heeft. 

Maar dat krijg je met geen mogelijkheid langs support geëscaleerd. 
 

Als je dan vervolgens middels:  smtp.t-mobilethuis.nlm37.143.82.162]:465 wilt verzenden 

Kun je wel met TLS verbinden maar kun je niet met een eigen domain name naar buiten mailen. 

Heeft iemand een oplossing gevonden? Zie ik iets over het hoofd? 
Of is t gewoon slecht geregeld bij T-Mobile met de Mail? 

Ik zit met hetzelfde. Is hier al (eindelijk) een oplossing voor?

Hi @carlavandenvelden, zou je je SMTP instellingen kunnen delen en de melding die je ontvangt bij het uitsturen van de e-mail? Dan zal ik hier eens verder induiken! 

:-) is er een update en/of een oplossing? Hier ook het probleem dat postfix niet via submission mail kan doorsturen. Ook als ik Evolution gebruik een mail te sturen via smtp.t-mobilethuis.nl:587 dan krijg ik de melding “ ‘Error performing TLS handshake: Er werd een onverwacht TLS-pakket ontvangen.’”

Hi @Raphael2023 welkom op onze Community!

Zou je je instellingen hier willen delen? Dan kan ik kijken of alles goed staat!

Dit probleem heb ik ook, sinds een jaar o.i.d.. Ik ben toevallig wel vrij specialistisch op dit gebied.
T-Mobile heeft ineens na vele jaren zich gehouden te hebben aan de Netneutraliteits wetgeving,
ineens besloten tcp25 outbound (outbound, gezien van klant-netwerk) te blokkeren. Een zeer hinderlijke trend, en feitelijk een juridische apenstreek. Ik heb er geen ander woord voor. Dit doen dit soort providers om op voor hen simpele wijze te voorkomen dat virussen e.a. infecties allerlei smtp berichten samenstellen en uitbraken via jouw ISP verbinding. Dat lijkt een valide reden maar is het geenszins. Gelukkig laat men inbound tcp25 nog wel toe, zodat ontvangst op een eigen smtp MTA nog mogelijk blijft, maar zorg dan wel dat je MTA qua relay beveiliging en backscattering correct is gebouwd. Als dat laatste niet zo is dan ben je sowieso zelf ook niet goed bezig, en zijn maatregelen wél gerechtvaardigd. Maar anders ligt dat dus voor tcp25 outbound.

Wel… toen ik er zo’n jaar geleden mee werd geconfronteerd moest ik dus ook ineens m’n eigen MTA systeem veranderen, zodat uitgaande smtp mail gerelayed zou worden via t-mobile MTA’s, waartoe je via TLS je credentials (encrypted) hanteert om vervolgens te mogen en kunnen sturen.  Dat gaat dus niet over tcp25+tls/ssl , maar via idd submission ports, en die staan wél open outbound. Ik was daarmee dus gered. (Ik had dus niet de issues die men hierboven beschrijft, maar die issues zijn wel herkenbaar, zij het meestal als configuratie en versioning fouten. Daar komt men uiteindelijk wel uit, en hoort bij encrypted channels + authenticatie.)
Echter “gered” onder protest want ik haat het als een ISP forceert dat ik via hen alles moet relayen omdat men om simplistische redenen poorten gaan blokkeren. What’s next ? tcp80 dicht ? Als ik geen 100% internet heb, wil ik ook niet 100% betalen. En wat gebeurt er idd op enig moment…. jawel… de T-mobile smtp mta’s stonden een tijdje op de blacklists bij big bad Microsoft O365. Dus mails aldaar werden gebounced, en niet omdat mijn MTA niet correct was, maar omdat T-Mobile kennelijk markers had opgelopen die het MS de redenen gaf dit te blokkeren. Mijn mails zijn overigens alle voorzien van correcte DKIM signaturen en ik beschik over correct SPF. Dat terzijde, maar om aan te geven dat de opmaak en headers van mijn mails laag scoren in (zelfs slechte/domme/rigide) anti-spam filters.
Anyhow, ik kon in die periode dus geen mails sturen een O365 contacten, en had OOK DUS
GEEN MOGELIJKHEID MEER om zelf de smtp routes op te lossen (DNS MX), zoals voorheen,
en zoals het hoort, en zoals je als internet-participant ook recht hebt, omdat tcp25 outbound
dus geblokkeerd was. (MX resolving lukt prima, uiteraard, maar vervolgens de mails naar
de ontvangende MTA (dest. tcp25) sturen is dan onmogelijk.)
(Nogmaals… netneutraliteit wordt dan heel creatief toegepast door T-Mobile, waardoor
je in het strafbankje zit, zonder schuldig te zijn. Dat is wel degelijk onbehoorlijk, en zou
opgelost kunnen worden door op verzoek van klant direct die blokkade op te heffen, zonder
enige (kansloze) discussie. Maar helaas.)
Maar goed… het is maar een voorbeeld van gedoe op Peppie en Kokkie level, als ISP’s zomaar rotzooien en je je recht ontnemen zonder enige nuance. Ik heb indertijd geprobeerd deze tcp25 block te laten verwijderen, zoals het ooit was, maar was kansloos. Men had geen idee wat het eigenlijk was, en kwam met de meest stupide argumenten. Terugbel-acties leverden ook niets anders op dan blijk van onkunde, en gepaard gaande onwil. Ook zo’n trend overigens. Gek genoeg weten ze wel heel goed hoe ze die blocks moeten inzetten.

De volgende angst diende zich deze week alweer aan; Men gaat de “e-mail dienst per
maart 2024” opheffen, zo schreef de mail. Het lijkt louter te gaan om de mailbox die bij hen ligt mbt het t-mobile-thuis account, maar ik ben op m’n hoede. De reden laat zich nl. raden, net als de tcp25 block… nl. “werk en onderhoud”. Men heeft er geen zin (meer) in, of behoefte aan, dus hop gaat het eruit. Dat mag, maar wat gebeurt er dan nog meer? Gaat de gehele mail omgeving eraan ? Bijv. ook de relay-MTA systemen ? En zo ja, gaat dan tcp25 wel ineens weer “open” om de klanten alsnog hun mails zelf te kunnen laten versturen via hun eigen systemen ? Al deze dingen blijken uit niks, maar ben wel bevreesd dat in maart 2024 ik ineens met een complete block geconfronteerd wordt en mijn gehele mailsysteem en maildomain voor mij en mijn on-system-accounts plotsklaps totaal onbruikbaar wordt, en kansloos te herstellen, immers
is de situatie dan dat zowel tcp25 als de relay MTA’s “verdwenen” zouden zijn.
Alleen al DAAROM vind ik, nee, eis ik, dat ik m’n recht terug zou moeten krijgen en gewoon die
tcp25 block opgeheven moet worden. Nu en voor altijd.

Nu is mijn frustratie al een oude en een lange, en ik baal daarvan want ik vond het T-mobile pakket altijd al least of the worst heden ten dage, en zou liever blijven, maar ik heb meer gedoe. Zo heeft men er ook een handje van gekregen om de TV dienst jaar na jaar steeds verder uit te kleden en te veranderen (spoelen, recording, etc. dat verhaal bespaar ik hier). En waar voorheen keurig met tijdstip en al onderhoud werd aangekondigd, is dat nu volledig arbitrair.  Soms wel, soms geen tijdstip/datum, soms helemaal geen bericht, maar wel ineens allerhande uitval en updates, met name net na 01:00 ‘s nachts. Meestal weet je niks, en gaat de boel ineens op zwart, valt je internet of TV weg, en zie je de setop boxen updaten. Wel altijd als patroon even na 01:00, en dat soort ongein.

Ik heb mezelf bij dit alles, van ergernis, een soort van neergelegd, en overweeg wel degelijk
om te vertrekken. Zeker nu met die recente mededeling van die mail. Contact gehad met helpdesk, wel, dat is nog kanslozer dan het tot 1.5 jaar geleden was. Slecht voor bloeddruk, en daar heb ik geen zin in met dit soort bedrijven. Ik ben klant, en wens ook zo gezien te worden. Mensen (zoals ikzelf) die Internet al kennen vanaf dag één, hun eigen systemen runnen zoals bedoeld (Unix, Linux, maar ook bijv.MS-Windows indien voldoende veilig ingericht qua architectuur en planning), en daar op niveau mee om gaan en kunnen gaan, hebben gewoon recht op hetgeen wat ze afnemen; nl. een internet-aansluiting. Internet is synoniem voor IP verkeer, en alle layers daarboven moeten daarover kunnen forwarden. Alle tcp, alle udp, icmp, alles. Poorten blokkeren blokkeert volledig mogelijkheden en functionaliteit. E.v.t. vermeende problemen daardoor, dient men ANDERS aan te pakken en op te lossen, op de plek waar het thuishoort nl. Zoals voorheen. Maar men aapt elkaar na; Als KPN en (voorheen XS4all) het ineens lijkt te kunnen flikken, “dan kunnen wij dat ook”. “Men snapt het toch niet, en de desk houden we dom”. Apenstreken, zij het als het erop aankomt ook nog eens juridisch gezien overtredingen. Maar het scheelt bakken onderhoud en werk m.b.t. veiligheden waar een ISP een rol in zou kunnen spelen. Maar dat hoort erbij.
Je gaat de snelweg ook niet ineens definitief blokkeren voor auto’s met een kleur die je niet
aanstaat, omdat in zwarte auto’s met geblindeerde ramen “altijd boeven rondrijden”.
Je doet dat niet, en het MAG OOK NIET, ook niet als er drogredenen tot in de afgrond
worden aangedragen.

Ter info, ter troost voor medefrustrado’s. We zullen zien wat de t-mobile toekomst brengt.

Prettige dag, groet.

Mooie rant @WPI-JCK en wij verschillen zo te lezen niet zo veel van elkaar. Ben je al overgestapt naar Freedom? Of ga je stoppen met zelf hosten?

Gewoon de SMTP server van google gebruiken voor relay dat doe ik ook.

Wel even een 16 character app password laten genereren in je google account admin anders kun je daar niet inloggen..

Iedereen zijn eigen keuze, maar de topic starter en ik zelf zouden graag niet onze e-mail versturen via een tech gigant uit de US. Zoals ik de discussie in meerdere topics zie zijn er 2 redelijke oplossingen.

1 Overstappen naar een ISP die je wel begrijpt. Dus kies met je portemonnee. Dit is mijn keuze.

2 Zet een VPSje op voor 1 Euro per maand en klats daar je eigen relay op. Dit heb ik ook getest en werkt prima en kan zelfs nog positief zijn voor je reputatie omdat je e-mail niet meer vanuit een IP adres komt die waarschijnlijk in een heleboel "dialup" IP blacklists staat.

Het blijkt ook niet te werken via de Google smtp server. Die veranderd namelijk in de header het return email adres naar het gmail adres van het account waarmee ik relay. Dus dat blijkt ook geen oplossing.

Antwoord zodat ik later deze post terug kan vinden.