Waarom krijg ik als ik TLS required uitzet op een mailbox toch de foutmelding dat TLS required is als ik een email via die mailbox verstuur?
Welke email-software gebruik je ?
Is dit ook met/bij Freedom webmail ?
Is het from/doeladres wel âwerkendâ met bv gmail ?
Gewoon webmail.
De betreffende ontvanger kan ik alleen antwoorden vanaf mijn eigen email adres, niet vanaf gmail.
Het moet iets met de Freedom email te maken hebben.
Ik heb iets dergelijks een paar keer meegemaakt.
Het bleek steeds aan de ontvangende kant te liggen, hoe vreemd dat ook mag klinken.
De helpdesk kan dit voor je uitzoeken.
Ik zou het vreemd vinden dat het aan de ontvangende kant ligt. Dan zou niemand naar die ontvanger iets kunnen sturen. Ik heb âTLS verplichtâ op mijn mailbox (eigen domein bij Freedom) echt uit staan.
Dan kan Freedom het toch niet alsnog verplicht laten zijn?
Heb het vanochtend nogmaals geprobeerd, maar na 16 uur sinds de verandering naar âTLS verplichtâ uit nog geen effect.
Naar een heel andere ontvanger gaat het op dezelfde manier mis. Daar kan ik mijn xs4all account voor gebruiken en dan gaat dat wel goed. Dus het ligt echt aan Freedom.
Heb je de exacte foutcode ?
Stuur je de mail met je âfreedom.nlâ mail of met je âeigen-domeinâ account ?
En op welk moment krijg je die foutcode⊠gelijk bij het indrukken van verzenden of dat de mail wordt gereject, en je dan in de ontvangende header kunt lezen waar het stokt.
Mogelijk dat daaruit kan worden afgeleid waar precies de fout zit.
NB: onder water kan sprake zijn van white/blacklisted adressen bij de ontvanger, die al of niet iets verplichten. Meldt dit hoofddomein aan de (ontvangende) helpdesk, die dan contact kan opnemen om je âeigen | freedomâ domein conform toe te voegen.
Ik ken verder situaties waar de ontvangende partij expliciet TLS inkomend vereist.
Met alle rat-race security wordt het leven alsmaar complexer.
Zoals aangegeven komt het bij twee heel verschillende ontvangers voor en bij Ă©Ă©n van de twee waar ik mijn xs4all email adres wel kan gebruiken is het geen probleem om dat via xs4all te bereiken. Dus met de ontvangers black/white listen van TLS heeft het niets te maken. Het is met âeigen domein bij Freedomâ. Ook lukt het dus in eerste instantie niet met TLS verplicht aan en dus ook na uitzetten niet.
Het is een email met een foutmelding dat versturen niet is gelukt.
Zonder gevoelige informatie (tussen â) is de foutmelding:
<[âemail adres ontvangerâ](mailto:âemail adres ontvangerâ)>: TLS is required, but was not offered by host
âserverâ[â server IPâ]
Reporting-MTA: dns; outbound.soverin.net
X-Postfix-Queue-ID: âsecret â
X-Postfix-Sender: rfc822; [â mijn email adresâ](mailto:âmijn email adres â)
Arrival-Date: âsecretâ
Final-Recipient: rfc822; [âemail adres ontvangerâ](mailto:âemail adres ontvangerâ)
Original-Recipient: rfc822;[âemail adres ontvangerâ](mailto:âemail adres ontvangerâ)
Action: failed
Status: 5.7.4
Diagnostic-Code: X-Postfix; TLS is required, but was not offered by host
âserverâ[â server IPâ]
Dat zou en kan iemand allemaal denken⊠ik zeg maar wat: als die ontvanger bv expliciet eist dat iemand die niet hun white-list staat, dan verplicht worden om met (opportunistisch met) TLS te werken. Kan allemaal zo (in)geregeld zijn dat de één wel en de ander niet (denk ook aan firewalls) werkt.
Sommige mail-ontvangers zeggen bv op query (START)TLS te bieden, terwijl dat niet eens is geconfigureerd en ik mij dan kan voorstellen dat Soverin dan - veiligheidshalve - 
afhaakt.
Dat een andere provider (xs4all), vrolijk doorgaat is dan weer iets waar ik het mijne van denk.
Boodschap 5.7.4. kan in principe van alles zijn â5.7.4 Security features not supportedâ
Het verhaal doet mij echt denken dat de ontvangende partij hier de boosdoener lijkt.
Of en hoe je die dan aanspreekt âzelfâ of via de helpdesk@freedom, is dan weer een ander - doorgaans moeizaam - verhaal om eerst door de level 1,2,3 barriĂšres te breken.
Bijkomend probleem voor Freedom is dat die weer (eerst) met Soverin (waar de mailfunctie is neergelegd) in-chat moeten gaan.
Probeer eventueel zelf te analyseren door gebruik te maken van https://www.mail-tester.com waar je - een mail naartoe stuurt waarop - ontvangende (mailheader) analyses kan laten uitvoeren. De site stelt dat ze niets inhoudelijk doen met je mail/data.
1 like
Dit dus.
Als je aan jouw kant TLS uitzet, maar de ontvanger zegt dat TLS verplicht is en dan vervolgens het protocol niet correct afhandelt krijg je deze foutmelding, been there, seen that, done that en zo.
Maar laat TS het aan de helpdesk vragen, die kunnen precies zien waar het fout gaat en waarom.
2 likes
Hier staat het antwoord denk ik.
De host (ontvangende partij) zegt dat TLS moet maar biedt het vervolgens niet aan.
Soverin eerbiedigt dat âTSL is requiredâ (ondanks dat het van jou niet hoeft, maar de tegenpartij zegt dat het wel moet) en dan loopt het spaak als die tegenpartij er niks mee doet.
Soverin doet het dus goed.
2 likes
NEE, dat zegt de host niet dat TLS required. Dat zegt Soverin zelf !!!
Ook: Want die foutmelding krijg ik NIET als ik het via xs4all stuur.
Vraag ligt bij helpdesk.
Het kan niet zo zijn dat ik mijn xs4all account moet gaan aanhouden om emails te kunnen sturen naar iedereen die ik wil.
Kan ook opportunistisch zijn dwz dat de ontvangende mail provider zegt dat die TLS slikt maar dat totaal niet heeft geconfigureerd of actief heeft. Meestal een foutje van de ontvangende site/installatie/beheerder. En ja, veel mailproviders gaan dan alsnog door met de mailsessie om toch te versturen waar ik dan weer iets van denkâŠ
Dat je dan als âgebruikerâ wil beslissen om je mail er doorheen te drukken⊠is dan iets waar je over kunt discussiĂ«ren.
Ik kan mij voorstellen dat Freedom hiervoor een keuzeoptie maakt en vraag mij af of Soverin (als privacy partij) hierin meegaat. De âfoutâ ligt immers aan de andere kant.
Zelf hou ik voor dit soort gevallen een gmail account waar ik kan mailen met partijen die geen privacy ondersteunen.
Eventueel kan je de ontvangende mailadres (gaat geruisloos) laten uittesten met https://www.checktls.com , benieuwd of wat die ervan gaat vinden.
1 like
ONJUIST
Lees eens wat ik schrijf!
In eerste instantie stond TLS required AAN !!! Toen ging het fout, foutmelding 1
Toen TLS required UIT gezet; Toen ging het weer fout, foutmelding 2
foutmelding 1 = foutmelding 2
Verzonden va XS4ALL, geen foutmelding, email komt aan, is bevestigd
Conclusie, TLS required staat bij Freedom/Soverin nog steeds AAN, terwijl ik heb gezegd dat die UIT moet.
Probleem ligt bij Soverin/Freedom die er niet voor zorgen dat email die ik verstuur aankomt als ik dat wil, ook als dat wat mij betreft onveilig mag, zonder TLS.
Als ik een van die email adressen waar ik email naar wil versturen en waarvan Soverin precies dezelfde foutmeldingen geeft met TLS reuqired AAN en UIT, test op https://www.checktls.com/ dan krijg ik als resultaat (ââsecretââ is door mij geplaatst op server naam van ontvanger):
Answer, Connect, HELO, From: OK
TLS, Cert, Secure: Fail
MTA-STS: no policy
DANE: no TLSA
In detail:
seconds test stage and result
[000.000] DNS LOOKUPS
[000.013] SEARCHLIST 104.131.108.216,134.209.169.224,1.1.1.1,8.8.8.8,67.207.67.3
[000.016] MX (10) mail.âsecret â
[000.117] Aâ>âsecret â âsecret â
[000.265] Aâ>mail.âsecret â âsecret â
[000.265] primary mail.âsecret â
[000.266] primaryâ>type MX
[000.266] primaryâ>DNSSEC? no
[000.360] policyâ>error could not retrieve policy: 500 Canât connect to mta-sts.âsecret â:443 (Name or service not known)
[000.361] mail.âsecret â MTA-STS not OK
seconds test stage and result
[000.000] Trying TLS on mail.âsecret â[âsecret â] (10)
[000.096] Server answered
[000.195] <ââ 220 h2784249.stratoserver.net ESMTP Exim 4.89 Sun, 10 Oct 2021 17:11:07 +0100
[000.195] We are allowed to connect
[000.195] ââ> EHLO www11-do.CheckTLS.com
[000.293] <ââ 250-h2784249.stratoserver.net Hello www11-do.checktls.com [167.71.160.115]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-PRDR
250 HELP
[000.293] We can use this server
[000.293] TLS is not an option on this server
[000.293] ââ> MAIL FROM:test@checktls.com
[000.389] <ââ 250 OK
[000.389] Sender is OK
Voor het hele andere email adres, waar ik iets naar toe wilde sturen, op een hele andere mailserver hetzelfde resultaat:
Answer, Connect, HELO, From: OK
TLS, Cert, Secure: Fail
MTA-STS: no policy
DANE: no TLSA
Wat ik me ook af vraag, hebben die TLS knopjes direct resultaat.
Of zit er een taak achter die het b.v. eens in de 90 minuten wijzigt.
Ik heb mijn vorige response verwijderd om de verwarring te verkleinen.
Je gaf een mooie opsomming, die het duidelijker maakte.
Als ik een mail naar een ander email adres van mijzelf stuur.
Staat er netjes bij iedere stap dat er TLS 1.3 gebruikt is.
Als je het knopje om zet, zou dat na een tijdje moeten verdwijnen.
Received: from outbound.soverin.net ([116.202.65.215])
by mijnandereprovider.invalid with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
TLS speelt zich op verschillende niveauâs af. Die van ons als client-server maar ook op server-server dus tussen Soverin en Target. Ik vermoed dat in die laatste het probleem zit, die tegen Soverin zegt dat TLS mogelijk is maar niet de secure mode in âhuisâ heeft (wat een "foutje"kan zijn). Dat xs4all of een ander dat dan negeert en doorgaat met de mailoperatie, zegt mogelijk meer over xs4allâs opportunisme dan over Soverinâs halsstarrigheid de boel te cancelen.
Dat je dan als gebruiker met de gebakken peren zit en mogelijk zou moeten kunnen kiezen om de mail alsnog door te drukken, is een andere (policy) zaak die Freedom maar moet bespreken met Soverin. Vooralsnog, voor mij, werkt het zoals het volgens mij moet.
Ik weet niet of ik het antwoord " TLS, Cert, Secure: Fail " , hier goed interpreteer. Het duidt mij dat er wel TLS & certificaten zijn maar secure connectie desondanks kennelijk niet mogelijk is. M.a.w. suggereren dat TLS mogelijk zou zijn maar geen secure verbinding mogelijk maken.
Check dit evt voor in-depth info: Opportunistic TLS - Wikipedia
(servers communiceren op poort 25 en schakelen indien STARTTLS wordt ondersteund dan over naar secure/encryptie).
Voor een verdere analyse is Soverin nodig die haar logs & checks moet doen. Ik moet het doen met wat ik waarneem en weet niet hoe precies het bij Soverin zit.
1 like
Niet helemaal juist.
Zover mij verteld is gebeurd namelijk het volgende als je het schuifje omzet:
-
TLS AAN: Het bericht wordt met TLS verstuurd. De andere server moet dit dan ook aan hebben staan. Heeft de ontvangende server dit niet? Dan krijg je de foutmelding en krijg je een bounce bericht.
-
TLS UIT: Het bericht wordt met TLS verstuurd. De andere server moet dit dan ook aan hebben staan. Heeft de ontvangende server dit niet? Dan wordt het mailtje zonder TLS afgeleverd.
Zover ik weet zou er geen tijdsverschil in moeten zitten. Tussen uitschakelen en dat je zonder TLS kan verzenden. Mocht dit niet zo zijn, willen we graag met de juiste gegevens een header hebben op de mail naar Freedom. Dan kunnen we onderzoeken of de schuifjes hun werk nog wel doen.
1 like
In beide gevallen TLS AAN en TLS UIT is de bounce foutmelding gelijk.
Bij TLS UIT wordt de email niet afgeleverd en krijg je dezelfde bounce foutmelding als met TLS AAN.
De gegevens van de andere servers (twee heel verschillende) is volgens https://www.checktls.com/ :
Answer, Connect, HELO, From: OK
TLS, Cert, Secure: Fail
MTA-STS: no policy
DANE: no TLSA
De mail met het probleem heb ik eerder van het weekend al naar jullie toegestuurd voor een oplossing. Daarin staan de detailgegevens die ik in deze openbare post heb verwijderd.
Dan ben ik benieuwd of Freedom (aka Soverin) dat zo doet, die lijkt hier overduidelijk vooraf checken of een site TLS heeft en dat doet.
Wanneer een site zegt dat die TLS heeft maar dat niet doet, is er wmb wat mis met die site.
Je zal, als je het goed wil doen, dan een tweede TLS optie moeten implementeren nl âignore TLSâ.
Uit de getoonde data van PeterB blijkt zonneklaar (TLS, Cert, Secure: Fail) dat de doeltarget zegt dat ze TLS hebben maar dat dus NIET levert, Terecht dan, wmb, dat Soverin de mail niet aflevert aan dit soort âRoqueâ sites.
NB: dit staat los wat de gebruiker wil/doet maar heeft alles te maken met dat server-2-server OOK via privacy regels moet verlopen.
Omdat het my intrigeert⊠het probleem zit/lag bij Strato (de doel mailgateway waaraan PeterB iets vertstuurt) die dat weer laat afhandelen dor hun ârz-ip.netâ domein. Die braaf alles doet wat nodig is voor TLS vervolgens niet omschakelde naar secure-mode.
Update 11okt21 13u51 as we speak: lijkt/heeft Strato de fout opgelost, Als het goed is zou PeterB nu wel zijn mail moeten kunnen versturen.
Geen idee hoe je aan die conclusie komt. Dat zegt de doeltarget helemaal niet! Dus zonneklaar is dat ook al niet.
Het is een test van https://www.checktls.com/ die faalt op TLS, zie ook het lange report. Daarin is overduidelijk dat het doeltarget helemaal niet zegt dat het TLS heeft, maar dat het een conclusie is van checktls dat het doeltarget dat niet levert.