Kan geen mail afleveren via AmazonSES (5.7.1)?

E-MAIL
,
21

:roll_eyes: FF in Ă©Ă©n 2 uur reactie.
tldr; @KoffieNu : zelf kunnen inrichten van een eigen SPF bij Freedom zou - deels - soelaas kunnen bieden ?
tldr; @pa4wdh : inrichten v.e. speciaal & op zichzelf staand (besloten mail)domein lijkt mij ook te overwegen.

Anderen worden daarin nergens bedreigd en moraal blijft wel dat Freedom die dat moet willen faciliteren waarbij ik bvk de mogelijkheid zou willen hebben om zonder gebruik van TLS/SSL mail te kunnen plaatsen op/in mijn mailbox. Mail die dus niet eens hoeft verzonden te worden aan derden.

@KoffieNu. Ik snap dat je zeg met take-it-or- leave-it het zelf maar moet zien te regelen.
Ik verschil van de zienwijze in hoeverre iets van jou of mij is en daarmee het de (on)mogelijkheid om iets te kunnen doen.
Ik ben meer dat iets ook een eigen keuze kan zijn en dit ook prima mogelijk is omdat het andersdenkenden nergens zal beletten om hun zienswijze te volgen.

De stelling dat een individuele “keuze” iets voor de provider onveiliger maakt is vooral hoe dat (dan) wordt ingericht. Wanneer ik thuis zijnde niet wil aanloggen maak dit jouw toegang niet anders of onveiliger.
Puur technisch voor die 5.7.1. zou het ws al helpen dat ik bv het SPF record op eigen domein bij mijnFreedom zou kunnen aanpassen.

@pa4wdh Goed geformuleerd en je zelf hier een beetje wat @Koffienu stelt dat het aan Freedomnet B.V. - los van naam dus een ordinair bedrijf - wat zij wel en niet wil/gaat bieden.
Ik heb wat moeite met de neoliberale insteek want ik zie mijzelf niet als klant van Freedomnet. B.V. maar als deelnemer die ook een investering doet om Freedom’s idealen in de meest wijdse zin van het woord ruimte te bieden (ook daar waar die fundamenteel ingaat tegen mijn eigen overtuigingen).

Vooralsnog blijf ik (naĂŻef? aannemen ?) dat Freedom het zelf ook anders wil om verschil te maken zodat iedereen bij Freedom dan de keuze heeft.
Anderen die dat niet wensen worden verder nergens in beperkt.

En idd, hoe denkt Freedom over zaken en hoe dan - hier - in dat ‘gesprek’ komen om het anders te kunnen doen ?

@Noci dank voor je technische uitleg met hoe het waarom op Internet zo is gekomen en hoe iets zou kunnen worden opgelost.
Ik maak wel een klein verschil in de de nuances.

Dat ik nu “moeilijk” doe, komt omdat ik sinds invoering TLS1.3 in februari ineens geen mailtjes aan mijn eigen mailbox kon versturen en dat nu via een omweg (extern o.a. AmazonSES) regel dat weer stuiterde op de 5.7.1. (dat ik weer anders omzeild door een derde mailpartij te gebruiken).
Ik baal dat ik voor iets eenvoudigs - dat veroorzaakt wordt door opgelegd beleid - een andere en zelfs derde partij nodig heb waar ik - daarvoor - het liefst zsm afscheid van zou nemen. Ik wil juist niet hebben dat ik via Amazon of wie dan ook zou moeten mailen.

Het is ook niet zo dat ik mijn maildomein en daarmee Freedom’s reputatie, te grabbel wil gooien. Ik zou er bv prima mee kunnen leven dat mijn mailbox een besloten karakter krijgt en alleen door en met mijn login bruikbaar wordt. iets dat trouwens ook simpel is in te stellen. Het is zelfs niet eens nodig dat mijn mailbox aan de MX-internet hangt.
Het volstaat dat we daarmee met onszelf SMTP/IMAP/POP3 kunnen doen.

Bv een mailbox aan te merken als voor intern of extern (dwz buiten mijn domein of dat van Freedom) gebruik. Dit kan deels nu al, door de MAIL/DNS uit te zetten. Extern kan er dan sws niet meer op/met dat domein worden gemaild.
Je suggestie om daarvoor een speciaal domein mijn part apart & ongekoppeld domein in te (kunnen) richten is daarin dan een variant waarvoor (ook) nauwelijks iets hoeft te worden aangepast. Hierbij is/blijft wel nodig dat ik als ‘mijn’ eigen keuze, zonder TLS/SSL mail kan plaatsen.

22

Je zou ook een proxy (SMTP-proxy) kunnen overwegen tussen je eigen apparaat met SSL/TLS-V1.antiek en de buitenwereld die al snel TLS v1.3 is.
Een SMTP proxy kan ook een heel eenvoudig ingericht email server zijn (Postfix, Exim, 
 ).

Freedom is idd een bedrijf
, “er wordt iets gedaan in ruil voor iets anders op een georganiseerde manier
”, bedrijf, vereniging etc. lijken juridisch heel erg veel op elkaar. Freedom is geen wereldwijde monopolist op mail gebied, dus Freedom zal met de andere mail gebruikers op het internet moeten samenwerken om het enigszins bruikbaar te houden.
Voor die samenwerking zijn er allerlei regels afgesproken (zie RFC’s rondom mail en hoe ermee om te gaan, een goede start is RFC 821).
Er is veel te zeggen voor de Anarchie op het internet alleen hebben enkelen er voor persoonlijk gewin ten koste van anderen er behoorlijk misbruik van gemaakt, en dan zijn er meer en meer regels noodzakelijk.
Een deel van die regels is dat tbv vertrouwelijkheid (tegen afluisteren) meer en meer SSL/TLS gebruikt wordt. TLS V1.2 is nu ongeveer 1 jaar geleden obsolete verklaart ivm. problemen TLS v1.1 en ouder zijn bewijsbaar gebroken en uberhaupt al afgevoerd.
TLS v1.2 is vorig jaar nog niet afgevoerd omdat niet iedereen als TLS v1.3 kon doen. Je mag verwachten dat TLS v1.3 langzamerhand het minimum zal worden op allerlei gebied.

mbt. SPF dat werkt op domein niveau
 dus heel freedom.nl en heel freedomnet.nl etc. niet voor adressen selectief.
Je kan natuurlijk een mailserver bouwen die dit anders regelt, of mogelijk kun je EXIM zodanig inrichten (geen eenvoudige configuratie) dat soms checks achterwege gelaten worden.
Voor de buitenwereld zal mail ZONDER TLS (beter dan V1.3) meer en meer een minimum eis zijn, dat heeft iets te maken met vertrouwelijkheid enzo
 (Al is er dan meer nodig zoals S/MIME dan wel PGP)
Heel veel op SMTP gebied is uitsluitend per domein in te stellen, dat is ook de verantwoordelijkheid van een MTA (Mail transfer Agent), en niet op per mail-adres niveau. De MTA levert lokaal te verwerken mailtjes af bij een MDA (Mail delivery Agent) die kan evt. ook extra controles doen en werkt dus duidelijk wel op mail-adres niveau.
Dat is nu eenmaal hoe SMTP etc. is ingericht en al jaren wordt misbruikt op alle manieren die nog mogelijk zijn.
Naast spamming is er ook nog Phishing waarbij “derden” zich proberen voor te doen als de legitieme afzender, dat was een use case die nog niet eerder noemde maar verdient zeker ook vermelding. Met het toelaten van Willekeurige" domeinen die vrijwel zeker (op technische criteria) niet de juiste bewijsmiddelen kunnen aandragen (juiste IP adres, Juiste domain, juiste credentials) is “vertrouwde” afzender niet in te voeren.

Voor mail als besloten groep (zonder connecties met het internet) heb je geen geregistreerd domein nodig
, dan kun je zelf binnen een server regelen.

2 likes
23

Ik denk dat jij in jouw geval 2 petten op hebt richting Freedom. De ene is als klant die de diensten gebruikt, de ander is deelnemer/investeerder. De eerste geeft jou dezelfde mogelijkheden als ieder ander: Heb je een klacht, meld het bij de helpdesk. Mogelijk dat die tweede jou iets meer mogelijkheden tot invloed geeft, dat weet ik niet.
Het lastige van de dingen die je vraagt (in deze vraag maar ook in je eerdere TLS gerelateerde vraag) is dat het gaat om dingen die alle klanten raakt, en dat maakt waarschijnlijk ook dat je hierop zoveel reacties krijgt.

Anderen worden inderdaad niet beperkt in wat ze kunnen doen, het beveiligingsniveau van hun dienstverlening wordt wel verlaagd om jouw use-case mogelijk te maken. Zeker bij een ISP die zich onderscheid door focus op beveiliging leidt dat tot weerstand.

Kleine nuancering: TLS1.3 is niet ingevoerd, maar onveiligere methoden zijn uitgefaseerd. Ze hebben een tijd naast elkaar bestaan om iedereen de mogelijkheid te geven te upgraden naar iets nieuwers en met de uitfasering is aan die mogelijkheid een einde gekomen.

2 likes
24

@Noci tldr; dank & heldere uitleg dat SPF geen soelaas biedt. Zelf wil ik geen eigen (proxy)server toepassen.
@pa4wdh tldr; gebruikers hebben geen (extra) risico wanneer iemand kiest om zonder ssl/tls mail te plaatsen. Kan zijn dat de reputatie als totale organisatie - met eigenheimers - wat minder uitblinkt. Eigenzinnigen die in het begin nuttig waren om later de plaat te gaan poetsen.

@Noci Mooi verhaal waarbij ik in aanvang alleen besloten wilde mailen, de redenen om spam tegen te gaan zijn mij duidelijk. Waar het om gaat dat ik nu geen keuze heb: of zelf doen of krom via een ander gaan truken.

Het bijplaatsen van een eigen server/proxy e.d. lost met de nodige moeite alles op maar wil ik juist voorkomen. Het zou ook niet eens nodig zijn wanneer wordt toegestaan om direct en rechtstreeks zonder “tls/ssl” mail in mijn gehuurde mailbox te plaatsen.

Dank voor je uitleg dat SPF aan de zijde van Freedom weinig soelaas zal bieden omdat SPF primair bedoeld is voor outbound naar Freedom toe. Verzenders kunnen dan checken of een (gehost) maildomein - evt. icm met (dkim/dmarc) - daar legitiem is.
NB die 5.7.1. van topic komt omdat ik vanuit AmazonSES namens mijzelf outbound mail en Freedom dan (SPF) “terecht”* (als beleid ?) zegt tegen Amazon dat dit niet d bedoeling is. Van Amazon krijg ik dan dat 5.7.1. mispoes bericht.
Amazon heeft daar weer vervolgtrucjes dat de medewerking vraagt van Freedom als administratief eigenaar van domeinen. Iets dat ik - hoe handig ook - zeker niet najaag omdat het allerlei consequenties kan hebben.

Kortom ik ben dan terug bij vakje 1: dat ik zelf mail wil kunnen plaatsen op/in mijn mailbox dat verder niet outbound hoeft te werken. Helaas verplicht Freedom/Soverin eindgebruikers tot TLS/SSL gebruik, ongeacht of die mail ook extern verstuurd gaat/moet worden. Een beleid om regels te kunnen (ver)vullen dat verder geen echte enkele functie heeft.

@pa4wdh ik heb primair de pet op van - betalend - verenigingslid en ga zeker niet in de rol van investeerder of aandeelhouder, ergens dingen forceren.

Ik kan deels volgen dat verandering een risico kan brengen voor anderen.Ik zie echter niet wat voor anderen het risico is wanneer ik zelf zonder tls/ssl mail zou kunnen plaatsen in mijn mailbox.
Hooguit dat ik zelf een “risico” loop dat iemand op mijn “internet” verbinding kan meesniffen of mailen om daarmee te gaan spammen. In theorie kan dan ook “onveilig” apparaat in mijn beheer, mijn eigen mailbox gaan voljagen om daarmee resources te belasten. Iets dan nu ook kan en verder niets te maken heeft met ssl/tls.

Goed & correct op te merken dat idd “alleen” de zg onveilige methoden van TLS zijn verwijderd als kennelijke opmaat om straks TLS1.3 te gaan opleggen. Helaas was dat a) onaangekondigd en mij b) in deze misùre lanceerde.

Een flink stuk irritatie zou voorkomen zijn wanneer Freedom eea vooraf FF tijdig had gemeld en niet wegmoffelde onder het mom van sorry-onderhoud.
Dat vonden zijzelf - helpdesk - overigens ook maar het Soverin kalf blijft wel in de gedempte put staan en ik snel een oplossing moest gaan zoeken (iets dat nu wel werkt maar niet mijn voorkeur had noch heeft).
Ik baal als een stekker dat ik voor zo iets eenvoudigs alsnog “Bigtech” moest inzetten.

Onverlet is het wmb valide dat Freedom een gebruiker de ssl/tls keuze moet laten. Precies zoals diezelfde gebruiker OOK per eigen mailadres/alias kan regelen om out&inbound ssl/tls uit te zetten.
Het inconsequente is dat ik als gebruiker mijn mail in ssl/tls modus moet inbrengen.

Wat overblijft is - en ik ook ergens weer kan volgen - dat de Freedom/Soverin als organisatie een “betrouwbare” reputatie wil hebben. Iets dat ik die ook zie bij andere wannabe’s zoals Protonmail of een Apple die hun gebruikers onderwerpen aan hun strikte regels om zo als doel te voldoen aan (veiligheids)normen.
In dat geval is Freedom buiten prima vertrouwelijk mailen met Soverin, mogelijk toch niet mijn innoverende partij om (mijn) andere IT elementen bij onder te gaan brengen.

25

Ik sluit de discussie af omdat ‘oorzaak’ van niet kunnen afleveren van op mijn eigen naam gestelde mail, ligt in gevoerd Freedom beleid waarover meningen verdeeld raken dat iets een ook bewuste keuzemogelijkheid kan zijn.

Kern(oorzaak) van de 5.7.1. mailblokkade is dat Freedom/Soverin als generiek SPF (antispam) beleid heeft (aangenomen?) dat mail met een eigen mailadres van en naar het eigen mailadres, bij Freedom; alleen vanuit het eigen (bij Freedom/Soverin ondergebrachte) domein mag worden verstuurd.

Het “antispam beleid” is intern verder zodanig vormgegeven dat een gebruiker geeneens een keuze heeft om het eigen mailadres buiten het Freedom domein te (laten) gebruiken als afzender naar de(zelfde) eigen Freedom omgeving.
Elders, laat staan wanneer je zelf een maildienst inricht, is deze constructie wel mogelijk door bv gebruik te maken van (eenmalig) voorafgaande verificatie.

Mijn (ondanks door AmazonSES geverifieerd recht tot) gebruik om uit naam van mijn Freedom mailadres te mailen naar Freedom, wordt dus simpelweg geblokkeerd.
Saillant is weer dat ik dat (zg spam) Freedom mailadres - volstrekt legitiem - wel elders bij mijn andere (e)mailpartijen mag en ook kan toepassen als legale afzender.
Freedom wijkt hierin dan wat af omdat zij het beleid heeft dat mail van “Freedom” alleen vanuit het “Freedom” (domein) mag worden verstuurd.

26

Hm als je niet heel erg geintereseerd bent in het IP adres dat je mailt kun je als proxy ook stunnel oid gebruiken.
Die aan de voorzijde netjes TLSv1.3 en aan de achter kant datgene wat je wil.
(HAproxy kan ook, is alleen wat lomp voor dit doel).

Het is niet dat TLS v1.3 opgelegd wordt, het is dat er tot nog toe SSL1, SSL2, SSL3, TLS1 (aka SSL4), TLS1.0, TLS1.1, TLS1.2 en TLS1.3 als protocol gemaakt zijn. SSL1 was tijdens de initiele presentatie door Mozilla Foundation al gekraakt. ( voor de implementatie),
SSL2 en 3 hebben het wat langer uitgehouden. TLS1 (naamswijziging omdat Microsoft van de SSL naam af wilde), t/m TLS1.1 een op SSL3 lijkende zwakheid hadden (aka gekraakt waren, door een aantal connectpogingen te doen was de sleutel te raden).
TLS1.2 had iets betere papieren maar heeft een (voorlopig theoretische) mogelijke zwakheid. 
 TLS1.3 is nu het laatste eitje in de mand van beschikbare protocollen.
Gebruik van oudere protocol is echt NIET meer verantwoordelijk.

Overigens zijn het de Microsofts, Googles etc. die TLS EISEN. Zonder TLS geen mail aflevering.
Zoals eerder gemeld, Freedom kan de wereld geen diktaat opleggen over hoe mail in te richten en zijn afhankelijk van de rest van de wereld. En “Justice is Switft” voor vrijwel iedereen die met het SPAM gevecht te maken heeft, Of hoort bij de “goeden” of je hoort bij “de gefilterden”
 Ontvanger bepaald dat beleid.
En door teveel te accepteren en mogelijk door te laten zit je heel snel in het zwarte gat.
Innovatie in E-Mail
 : verzin een manier om SPAM definitief om te leggen zonder nodeloze slachtoffers
, 99+% van de wereld bevolking zal je dankbaar zijn.
Het omlaag schroeven en enige vorm van veiligheid is geen optie, die zal verder omhoog moeten.

27

We spreken wat langs elkaar heen of ik kan niet duidelijk maken wat het issue is.
Ik snap meer dan wat jij en anderen allemaal inbrengen. Items die hier veel te wijds & groot worden aangehaald. Het gaat uit van een grote boze wereld om ons heen (en Freedom’s positie of “reputatie”) waarbij allerlei (veiligheids)eisen nodig zijn om dingen met & door anderen ordentelijk te kunnen laten gebeuren. Soit en so be it.

Zelf wil ik met ons “mailaccount” niet eens (kunnen) in/outbound kunnen mailen met en in die wereld, laat staan met “anderen” dan alleen ons innerlijke zelf. Iets dat prima zou kunnen wanneer Freedom ssl/tls toegang niet zou opleggen aan haar gebruikers.
Ik wil simpel de eigen platte statusmail bvk op naam van “ons” Freedom account op & in mijn eigen mailbox kunnen afleveren. Die mailbox wordt dan elders weer met IMAP (omdat POP3 helaas, ook niet meer mogelijk is) connectie uitgelezen.
Die situatie is niet zo absurd als wordt gedacht voor allerlei embedded clients die zelf(s) niet (kunnen) beschikken over vereiste whatever tls/ssl moderniteiten.

Die mailbox hoeft en kan zelfs bij voorkeur niet eens met andere mailomgevingen in verbinding staan. Iets dat we nu (omslachtig) afschermen met rules e.d.
Dat de “mailbox” via IMAP alleen met SSL/TLS kan worden ingezien, hebben we wat minder probleem mee.
Het gaat puur dat een mailinhoud in/op/naar de mailbox kunnen plaatsen dat we helaas nu via een omweg moeten via een “externe” proxy provider.

Het 5.7.1. verhaal zelf hier is dat het ronduit jammer is dat we de afzender van onze mail niet op naam van het eigen domein mogen zetten omdat Freedom dat als haar zelf verkozen (antispam) beleid afketst met die 5.7.1.
Elders zoals bv bij Polarismail, smtp2go (of ook Amazon en bv Google) en onze andere mailproviders is dat allemaal geen probleem.
Ik wilde juist pogen om geen gebruik te hoeven maken iemand anders dan alleen Freedom. Maar goed, dit station lijkt inmiddels een langdradig eindstation en we lossen het wel anders - maar helaas zonder Freedom - op. Thx4Fish.

28

Als je mail omgeving niet gebruik moet maken van SMTP dan is TLS een non-issue, wat je dan nodig hebt is een IMAP client of copier.
zoals ImapSync, zodat je mailboxen van a → b kan repliceren, syncen etc

Al zullen die in de nabije toekomst ook alleen TLS 1.3 spreken omdat openssl en ander SSL libraries langzamerhand gebroken protocollen uitfaseren.
GitHub - imapsync/imapsync: Imapsync is an IMAP transfers tool. The purpose of imapsync is to migrate IMAP accounts or to backup IMAP accounts. IMAP is one of the three current standard protocols to access mailboxes, the two others are POP3 and HTTP with webmails, webmails are often tied to an IMAP server. Upstream website is

1 like
29

Yep als ik geen SMTP zou - hoeven - doen, had ik “ook” geen ssl/tls issue.

Wat je (goed te weten, thx) noemt is allemaal NIET aanwezig in de gereedschapskist van de Freedom omgeving. Het zou idd wel cool zijn als we in staat zouden zijn om op provider niveau, onze mailboxen te repliceren met idd zoiets als imapsync.
Qua IMAP bij Freedom, is dat onderworpen aan dezelfde ssl/tls toegangseisen (waarin ik als “gebruiker” eveneens geen keuze wordt gelaten: “gij zult hier knielen”).
En dan nog, onze embedded clients hier ondersteunen al helemaal geen IMAP en we wilden voor die platte-statusmail, geen “eigen” in huis proxy/server zooi gaan opstellen.
Dat is dan idd ook soort van “keuze” en ik mij wat vergaloppeerde te willen (be)denken dat we onze simpele “mail” prachtig bij/met Freedom zouden kunnen onderbrengen.

Inmiddels hebben we het zonder Freedom opgelost.
Onverlet is het rigide dat allerlei veiligheidsmaatregelen als doel worden opgedrongen aan bewuste gebruikers.
Iemand zou zelf moeten kunnen bepalen of die zijn “gehuurde” object vult of leegt met welke whatever type ssl/tls connectie. Zolang een keuze anderen niet benadeeld, moet het credo zijn: leef je vooral uit (ook als dat volgens “deskundigen” oliedom zou zijn).

Wat een provider hoort te doen is standaard een veilige keuze bieden en niet als dictator die “zienswijze” als enige “mores” opleggen.

Vrijheid en netneutraliteit is niet anderen buitensluiten onder het mom dat andersdenkenden *daarvoor “kunnen” kiezen.

30

De kern van het probleem is dat door nieuwe aanvalstechnieken iets wat vroeger veilig was. (DES) dat nu niet meer is, dat iets wat vroeger zeer goed werkte (SSL2/3) dat nu niet meer doet.
SSL1 - t/m TLS1.1 zijn gekraakt (aantoonbaar, in real life) TLS1.2 heeft in 2022 het voordeel van de twijfel gekregen i.c.m. gebrek aan voldoende TLS v1.3 implementaties
 Dat laatste gebrek is inmiddels opgeheven, dat betekent ook dat er organisaties zullen zijn die gebruik van TLS v1.2 gaan opdoeken.
De veilige keuze is TLS 1.3 en als je iets anders (onveiligs) wil dan mag dat op geen enkele manier bij de veilige omgeving kunnen komen. 
 Dus er is in dit geval weinig tussenweg.
IMAP sync kan best een TLSv1.3 aan de ene kant met een andere verbinding (zelfs in Clear) syncen als je dat wilm vandaar dat ik die noemde. IMAPsync draai je trouwens net als een mail client in eigen beheer het is gewoon een commandline tooltje.

Een Analoog equivalent:
Als je weet dat je cilinder slot met hamer en schroevendraaier met een tik is te openen dan neem je maatregelen waardoor de schroevendraaier (oid) niet meer op de cylinder kan komen.
Oude cylinder sloten zijn op die manier obsolete geworden
 Als een schroevendraaier een universele sleutel geworden is dan zijn er dus geen sloten meer.
Jij verwacht in je voordeur waarschijnlijk ook een deugdelijk slot en niet een simpel koffer hangslotje waar er maar 13 verschillende sleutels wereldwijd van bestaan. (Ieder douane kantoor heeft een paar van die setjes van 13 liggen).
En een deugdelijk slot in de voordeur betekent ook dat de achterdeur een deugdelijk slot moet hebben
SSL1 t/m TLSV1,1 zijn een simpel koffer hangslotje geworden
 TLS V1.2 is ook een hangslot, maar niet met een hamertik te openen, TLS V1.3 is voorlopig het best mogelijke slot.
En een tweede ingang op een IMAP server met slechtere encryptie (vgl kofferhangslot op de achterdeur) is dus geen goed plan.
In dat geval moet de opslag maar in de schuur achter in de tuin gedaan worden, ie. niet onder de vlag van freedom.nl / freedomnet.nl.

Er was ooit wiskundig aangetoond dat SSL2/3 etc. goed en veilig waren, later hebben mensen eerst betoogd, en daarna laten zien dat er een paar onvoorziene (en door snellere hardware), uitgangspunten van de originele bewijzen niet meer standhielden. ==> er is afscheid genomen van inmiddels ingehaalde software. Er is geen vooropgesteld plan om TLS v1.3 in t voeren om het maar in te voeren als mooiste nieuwste bling bling item. Het probleem is dat andere zaken krakend in elkaar gezakt zijn er er op dit moment nog een stut de zaak overeind houdt.
Als je dat dictatuur noemt zit je m.i. op het verkeerde spoor
, of het is de dictatuur van de wiskunde.

2 likes
31

tldr; technisch heb ik elders mijn probleem opgelost en we tokkelen wat verder over de werkwijze en zienwijzen aaangaande veiligheid in relatie tot het gebruik van (mail) toegang.

Leuk & informatief maar die veiligheid aangaande techniek en kern is hier niet mijn betoog is vooral een (toe)geĂ«igende zienswijze. Je technische insteek wordt “dictatoriaal” ingezet om gebruikers die welbewust voor zichzelf GEEN beveiliging wensen, daartoe toch verplicht onderworpen.

We hebben een andere perceptie van & over veiligheid, het gebruik en laat staan in welk situatie(s). Dat (wis)kunde een ‘feit’ aantoont, wil niet zeggen dat het feit dus bepalend wordt voor de regels aangaande het gebruik en handelen. Een insteek die ik regelmatig waarneem.
Voorbeeld: Messen kunnen aantoonbaar gebruikt worden om te doden, dat geenszins wil zeggen dat iedereen met een mes het dus gebruikt om te doden en dus het bezit van messen verboden moeten worden of in een vergrendelde kluis moet worden bewaard.

Prima dat Freedom zelf als organisatie met andere providers een voortouw wil hebben om op een betrouwbare wijze; (ook mijn) mail superveilig volgens laatste (privacy) normen met en naar andere (gebruikers) uit te wisselen.
Iemand die mail alleen zo veilig wil kunnen versturen of die zo ontvangen, zou daarin (mijn part als default) toch de keuze moeten hebben. Hoe verwerpelijk een ander dat ook zou (en mag) vinden.
Dit geldt wmb niet alleen voor mail maar eigenlijk alles dat een eigen verantwoording moet kunnen zijn van een gebruiker zelf.
Wanneer ik mijn #hashcode van mijn ₿itcoinwallet op Insta wil zetten, moet ik dat heus zelf weten. Hooguit dat Meta mij nog vraagt of dat wel mijn goede idee is.

Freedom moet in al die zaken die gebruikers zelf aangaat en andere niet schaadt netneutraal zijn. Ook als het gaat om de keuze van veiligheid(snormen) als toegang en het gebruik van mail.

De Freedom implementatie zou niet mogen veroorzaken dat ik als gebruiker dan mijn mail alleen nog maar op haar voorgeschreven wijze zo mag toepassen. Hooguit dat, Freedom, wanneer er klachten zijn door MIJN handelen, mij het veroorzaken daarvan ontzegt.
Mijn vrijheid stopt waar die de vrijheid van anderen geweld gaat aandoen.
Dat ik onveilig een mail aan mijzelf wil versturen, gaat verder alleen mij(zelf) aan.

Kortom, beveiliging een keuze of iemand met ssl/tls kan aanloggen of hoe een maildienst wil gebruiken of dat toepassen met gelijkgestemde anderen.
Het is wmb NIET aan de provider - of het nu Microsoft of Freedom is, om zelf te beslissen over de uitwisselbaarheid van mail tussen gebruikers.
Hooguit dat een provider daar zelf een kwaliteitswaarde aan hangt dat dan weer gebruik kan worden door gelijkgestemde ontvanger(s) om die mail al of niet te accepteren.

32

Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.