Merkwaardig, want XS4ALL maakt dit al jaren mogelijk via een beveiligde verbinding. Je moet het in de e-mail client wel zelf even configureren. De informatie hoe dit te doen staat al jaren op de website van deze ISP.

Je interpreteert het bericht verkeerd, geloof ik. Het is niet zo dat ze nu pas versleutelde verbindingen gaan ondersteunen, het punt is dat ze stoppen de onversleutelde verbinding op poort 25 te ondersteunen.

Op zich snap ik de maatregel. Als je nu nog onversleuteld - al dan niet via poort 25 - mail aan het verzenden bent, is het misschien wel beter dat je voor deze dienst wordt afgesloten.

Anderzijds, vanuit het oogpunt van netneutraliteit is dit nogal dubieus. Het zou beter zijn als ze poort 25 default blokken en dat klanten op verzoek de poort open kunnen laten zetten. Als iemand om wat voor reden dan ook poort 25 wil gebruiken en die vraagt dat zelf aan, is die ook zelf verantwoordelijk voor zorgvuldig gebruik. Vanuit het generiek blokkeren vult de provider zijn zorgplicht in. Best of both worlds...

Het gaat er niet om of de provider het mogelijk maakt beveiligd te versturen, dat zal T-Mobile vast ook wel kunnen, maar
dat het onmogelijk gemaakt wordt om poort 25 te gebruiken.
Dat gaat niet zozeer om het onbeveiligd versturen (ook via poort 25 kun je beveiligd versturen) maar om het lastig te maken
voor malware om spam te versturen vanaf computers van klanten.
Hoe het bij XS4ALL werkt is niet zo relevant meer, dit is een provider in liquidatie en alle klanten worden overgezet naar
KPN internet waar het toch allemaal net wat minder geavanceerd is. Bijvoorbeeld een door de klant instelbaar poortfilter
dat heb je daar echt niet meer...

Sterker nog het is natuurlijk klinklare onzin dat we het hier hebben over een verouderde poort het is niet de poort die bepaald hoe veilig er verstuurd wordt maar de versleuteling en authenticatie procedure erachter.
Bedoel als dat echt hun doel was zouden ze ook meteen 465 moeten blokkeren wat maar ooit 1 maand in 1997 vanuit IETF de standaard is geweest voor SMTPs maar tegenwoordig dient het officieel voor URL Rendezvous Directory for SSM en heeft het niks meer met SMTP en implicit TLS te maken.

Houdt dat iedereen in de wereld tegen om 465 nog te gebruiken absoluut niet.
https://www.t-mobile.nl/Consumer/media/pdf/klantenservice/thuis/handleidingen/thuis-handleiding-email-instellen.pdf

T-mobile doet er verstandig aan gewoon TLS af te dwingen met beperkte hoeveelheid soorten ciphers in plaats van een poort te blokkeren. Dan ben je echt met veiligheid bezig nu ben je alleen maar bezig gebruikers te frustreren maar belangrijker je zelf werk op de hals te halen.

Mag dit, qua netneutraliteit?

Bedoeld T-Mobile niet dat ze poort 25 dichtzetten zodat je zelf geen smtp server meer kan draaien... en dat is, vind ik, een verkeerde maatregel maar goed, andere providers doen het al.

Volgens mij doet Ziggo iets vergelijkbaars al meer dan 10 jaar. Poort 25 is alleen bruikbaar voor verbinden met de mailservers van Ziggo. Verkeer via die poort naar elders is al heel lang geblokkeerd.

poort 25 voor mail submit is al ontzettend lang deprecated .

Officieel voor directory SSM ? Ik zie daar geen registratie datum bij , in tegenstelling tot message submit over TLS op tcp/465.
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=465

De huidige standaard is echt TCP/465 voor message submet over TLS .


TCP/25 voor mail submit is gewoon niet meer van deze tijd . (itt tot de functie van mail transfer ) .

https://www.rfc-editor.org/rfc/rfc8314.html#section-7.3

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=465
urd 465 tcp URL Rendezvous Directory for SSM [Toerless_Eckert] [Toerless_Eckert]

mijn pdu's en UPSen draaien nog op smtp 25 via tmob thuis..
sommigen kunnen geen tls draaien en smtp naar mijn eigen server wordt geblokkeerd door tmob...
onhandig dus

Wel - dat is een RFC op de standards track die gewoon expliciet zegt "foutje, het wordt/blijft toch weer TCP/465 voor mail submit altijd over TLS " .
En jammer dan dat de poort ook even toegewezen geweest is aan het urd protocol van één vendor.

TCP587 was een tijd lang de aanbevolen poort voor Mail Submit , waarbij TLS *optioneel* was - namelijk met het STARTTLS commando .

RFC 8314 zegt daarover in de appendix A dat dat gewoon niet bleek te werken, en dat op basis van operationele ervaring een dedicated "altijd TLS" poort te verkiezen is boven een protocol commando om TLS aan te zetten.

De afweging is naar installed base een van originele plaintext protocol geleidelijk naar TLS migreren kan door een STARTTLS optie toe te voegen , maar dat geeft code complexiteit met bewezen risico's .En een actieve MITM kan gewoon de client voorspiegelen dat de server geen STARTTLS support, waarna de client typisch zal terugvallen naar de oude 'plaintext' stijl.

Voor SMTP Transport - over TCP/25 blijft de keus duidelijk STARTTLS , ik ken geen beweging om een SMTP Transport met TLS op een aparte poort te gaan zetten. MX record is geen SRV record .

De helpdesk tekst is lastig te vertalen, maar ik lees vooral dat ze TCP/25 naar "buiten het T-Mobile" netwerk dicht gaan zetten.

Een thuis-server die zelf mail verzend naar 'de wereld' zal dan niet meer werken.
Het gebruiken van een externe smarthost over tcp/25 (heel erg deprecated in die rol) zal dan ook niet meer werken.

Overigens is met alle spam filtering het toch al behoorlijk zinloos geworden om kleinschalig een verzendende mailserver te draaien in "eindgebruiker IP space" , dat geeft zoveel negatieve scores om allerlei redenen dat veel mail niet meer gezien wordt.

Alleen zal men zich vrijwel altijd aan de RFC's hebben gehouden en versleutelde SMTP niet op poort 25 hebben gezet. En T-Mobile heeft het ook over hun eigen mailservers, geloof ik.
Heb je door dat het niet T-Mobile is die deze poort noemt in hun bericht maar dat het de redactie van security.nl is die het erover heeft? Dat zegt dus niets over wat T-Mobile goed of fout doet.

Klopt. Ziggo heeft dit opeens stop gezet zonder de klanten in te lichten. Heb mij ongeveer 2 jaar afgevraagd waarom het niet meer werkte en de klantenservice had ook geen enkel idee. Totdat ik het op een dag per toeval las.

Ja XS4ALL heeft dat ook geblokkeerd onlangs.
Dat soort apparatuur krijgt het moeilijk.
Wat bij XS4ALL nog werkt is de MX server van XS4ALL instellen als smarthost in je apparatuur, en dan mail sturen
naar een mailadres binnen XS4ALL (waar die MX server de mail voor aanpakt).
Je kunt opzoeken met dig of nslookup of whatever what je MX server voor je T-Mobile mail adres is en daar van het
adres instellen als smarthost in je UPS en kijken of het dan werkt.

Gelukkig kun je vaak de mailserver van je provider als relay gebruiken. Dan stuurt die het de weide wereld in , na een spamcheck. En als SPF record gebruik je een 'include' naar die van je provider.


Klopt eigenlijk alle dynamische IP adressen staan op veel blacklists. Dan weer je al veel spam dat via botnets rechtstreeks vanaf een pc de wereld ingestuurd wordt.

Functioneel - ja , dat is hoe je "normaal" als mailclient mail stuurt .

Waar ik geen duidelijk beeld van heb hoe normaal het 'nog' is voor een ISP smarthost om de submit op TCP/25 zonder authenticatie te accepteren, ook al is het van clients uit het eigen netwerk.

Uiteindelijk - de ISP MX'en (dwz, de servers genoemd in het MX record) hoeven geen relay/smarthost functie te hebben, ook niet voor eigen klanten .
De MXen zijn er om mail te ontvangen voor het domein waarvoor ze genoemd zijn - een andere rol hoeven ze niet op zich te nemen.

De pool van verzende mailservers van een ISP kan totaal anders zijn dan de pool van MXen.

En evenzeer - de pool van smarthosts , dwz de "mailservers" die de klanten instellen in hun mailclient om mail door te laten versturen kan ook een andere zijn dan de verzendende servers van de ISP, of de ontvangende MXen.
Er is best een hoop voor te zeggen als ISP om die smarthosts alleen tcp/465 en tcp/587 (beiden met authenticatie) te laten accepteren.

En natuurlijk, de pool van servers waar gebruikers de mail vanaf halen (IMAP4, POP3, nfs+elm/mutt/pine e.a.) is ook een separate functie.

Kleinschalig, en klassiek zat deze functionaliteit op één server, en zat het smtp-deel (submit, send, receive) in één programma (sendmail), of in één collectie van daemons (postfix, exim e.a.) .

Er zijn goede redenen om als ISP architect die rollen op gescheiden systemen (en separate IP adressen) te houden .


Mensen met echt oude meuk als mail-bron (zoals afgeschreven PDUs en UPSen) zijn vaak beperkt tot tcp/25 en zonder authenticatie bij het instellen van "de" mailserver .
Als workaround zouden ze natuurlijk dan maar een rPI kunnen bouwen als lokale smarthost (die dan eventueel de ISP server op tcp/465 of tcp/587 gebruikt ) .

Doet T-Mobile ook al jaren, merkwaardige reactie. Het gaat niet over mogelijk maken van verzenden via beveiligde verbinding. Het gaat over het onmogelijk maken van verzenden via onbeveiligde verbinding.

Als je dit schrijft dan heb je het klassieke SMTP protocol en de rol van smarthosts en mx hosts nog niet goed begrepen!
Een MX host werkt met exact hetzelfde protocol als een smarthost! En als de bestemming van de mail een adres is
waarvoor deze MX host als MX host wil werken, dan doet ie exact hetzelfde als wat een smarthost doet.

Het enige waar het kritiek wordt is of de MX hosts bereikbaar zijn vanaf het aansluitnetwerk waar de klanten met hun
ouderwetse UPS enzo op zitten. Als dat niet het geval is dan is dat scenario niet mogelijk nee, maar als dat wel zo
is dan zullen die MX hosts (in tegenstelling tot wellicht de smarthost) ALTIJD platte ongeauthenticeerde poort 25
mail accepteren. Dat is namelijk de standaard voor dergelijke servers.

Bij XS4ALL wat ik als voorbeeld gaf is er geen poortfiltering (als je dat zelf niet wilt) maar is wel de ongeautenticeerde
en ongecrypte aanlevering op poort 25 van mail op de smarthost uitgefaseerd. Daar liepen ook mensen tegen dit
probleem aan maar dit was dus simpelweg op te lossen door een van de MX hosts in te stellen als smarthost in
de betreffende spulletjes. Uiteraard alleen als de mail naar een @xs4all.nl adres gestuurd moet worden!
Het zou goed kunnen dat dit bij T-Mobile ook nog gewoon werkt, maar uiteraard wel met een t-mobile adres dan.

Het zal meer mogen dan de poort hijacken en naar een eigen SMTP server redirecten.

Volgens mij wordt TLS ook ondersteund op poort 25 hoor.

Het is sofisterij om smarthost te herdefinieren tot "smarthost voor het domein waar de MX mail voor aanpakt" .
Misschien is het goed genoeg voor het doel - maar dat maakt een MX geen 'smarthost' .

Vind je nou werkelijk dat de klassieke definitie van smarthost slaat op "alleen het domein waar de host MX voor is " ?

De 'smart' slaat echt op het feit dat de smarthost nu juist alle mailbestemmingen kan doen.

Als je echt weet wat je doet kun je je realiseren dat het moet werken om mail binnen het domein van de MX te krijgen.
Je ISP MX instellen om de mail op je gmail te krijgen heeft een grote kans om te mislukken.

Als de alarmmails van je oude UPS bij jan@gmail , kees@zonnet en piet@hetnet wilt krijgen, heb je een smarthost nodig.

En kun je niet truuken door een MX op te zoeken van het bestemmingsdomein en die als ' DE smtp server' in te vullen.


Wel - na de nodige spamfiltering waarin "direct to MX from enduser IP space" geen aanbeveling is.
De MX van de eigen ISP zal wellicht wat coulanter zijn voor eigen IP space, maar zelfs dat hoeft niet - het 99.9% scenario is toch dat eindklanten niet met MXen praten.


Ah, je weet achteraf toch dat smarthost wat universeler is - en een andere rol - dan "MX voor één domein" .

Poort 25 wordt, als het goed geconfigureerd is, nog maar gebruikt voor de communicatie tussen verschillende SMTP-servers. Niet om als client met een SMTP-server te communiceren. Als de uitgaande poort 25 dicht gaat, is het niet meer mogelijk om een eigen mailserver lokaal de draaien, die mails kan versturen. Dat is de praktische impact.

En toch vind ik het niet goed om als provider bepaalde poorts de blokkeren. Optioneel ja, voor iedereen nee.