Wat interessant.
Ik heb geen gmail, maar is het echt zo dat als je gmail hebt dat je dan de hele tijd op nieuwsbrieven komt waar je je
van moet afmelden?
En denk je dat dat aan gmail ligt? Ik denk eerder dat het aan de verzender van de nieuwsbrieven ligt.
Of aan je eigen gedrag. Vaak als je je ergens aanmeldt staat er een vinkje "ik wil geinformeerd worden" wat standaard
aan staat maar wat je gewoon uit kunt zetten, en dan kom je niet op die nieuwsbrief lijst.
Als je dat gedrag niet aanpast gaat een andere email provider je ook niet helpen.

Hi, TS hier,

De nieuwsbrieven ligt wel echt aan mijn gedrag. Dit is mijn email sinds ik 12 ben (10 jaar geleden). Ik let er tegenwoord wel op waar ik mij inschrijf en de vinkjes, maar heb nog de "legacy" lijsten die eens in de zoveel tijd met soort gelijke bedrijven gedeeld wordt, giveaway voor product x van bedrijf y en 2 maanden later een nieuwsbrief/marketing mail voor product x van bedrijf z.
Ik check regelmatig HaveIbeenpwned en het is een wonder dat hij daar nog niet geflagged is.

Proton mail scoort goed op privacy, en biedt ook allerlei andere gerelateerde diensten waarmee het concurreert met Google/MS/etc.

Met een vers mail adres maak je wel weer een verse start, maar dan moet je wel zorgen dat je niet weer op heel veel nieuwsbrieven terechtkomt.

Of je neemt een domein naam, dan kun je registreren met <webshopnaam>@example.com Krijg je inzicht in wie je mail adres lekt, en kun je die eenvoudig blokkeren.

https://soverin.net of https://greenhost.net zou ik ook naar kijken.

Ja precies, als je enige probleem is dat je gmail adres bij te veel mensen en bedrijven bekend geworden is dan kun je ook gewoon een ander gmail adres aanmaken en de zaken die je wilt houden daar naar over zetten.
Dat is net zo veel werk als naar een andere provider overstappen.

Een eigen domein en dan een apart mail adres per dienst dat is ook een goed idee, dat doe ik ook zo.
Dan kun je zien wie er je adres doorgeeft aan anderen en je kunt die adressen aan jouw kant blokkeren zonder gedoe.

Soverin.net is een Nederlands bedrijf, daar zou ik dan de voorkeur aan geven boven een vage "wij zijn veilig en loggen niks" dienst die wellicht anders handelt dan ze beloven.

Ik denk dat je sneller klaar bent door 's door de oude mail te gaan en die dingen actief te un-subscriben dan je hele boel over te zetten naar een ander mail adres.

Ik heb maar dan 25 jaar hetzelfde mail adres.. ja mijn mailadres is op heel veel plaatsen gebruikt. Ja en ook ik ontvang spam.. maar ik meld altijd nets af.. en de hardnekkige verzenders komen op de blacklist. Maar als ik 3 tot 4 spam mails per week krijg is veel..

Waarom overstappen naar een andere mail provider? Het lost niets op.. op termijn heb toch weer last van spam.

Nieuw gmail adres aanmaken en beide blijven gebruiken?

We kunnen nu natuurlijk 10tallen email providers noemen, maar welke eisen en wensen heb jij precies?

Ik vermoed dat TS weg wil van Google en daarom geen Gmail meer wil gebruiken. TS heeft er wellicht genoeg van dat zijn data wordt misbruikt ten gunste van de commerciele activiteiten van Google, als ik zijn tekst lees

Ik heb een eigen domein en selfhosted mail server voor serieuze zaken en zeer zelden spam.
Ik heb diverse Gmail en Hotmail accounts voor nieuwsbrieven etc. maar zelfs daarom komt nauwelijks spam op binnen als je er een beetje bewust mee omgaat.

Misschien ook handig om te leren is plus adressering
https://www.fastmail.help/hc/en-us/articles/360060591053-Plus-addressing-and-subdomain-addressing

Als je je bij nieuwsbrieven aanmeld met gebruikersnaam+tweakers@gmail.com en tweakers zou je email adres delen/verkopen en men gaat op dat adres spammen kan je zien waar het gelekt is.

Ik gebruik dit bij alles waar ik mij voor aanmeld.

Denk je dat iemand die adressen wil doorverkopen niet snapt dat ie eerst even alles achter een + teken moet weghalen?
Trouwens, er zijn heel veel plekken waar een + in een e-mail adres wordt afgekeurd als "ongeldig karakter".
Misschien niet bij e-mail lijsten die draaien op opensource of commerciele lijstservers, waar men het voordeel hiervan
wel kent (niet tegen adressen doorverkopen maar als gemakkelijk matching criterium voor het plaatsen van de mail in
mappen), maar als je gewoon ergens je mail adres moet opgeven voor een account ofzo dan wordt het heel vaak afgekeurd.

De titel zegt managed email provider maar alles uit je verhaal wijst op unmannaged.
Welk van de twee wil je?

Managed is peperduur en je geeft privacy op want je neemt een contract bij een beheerder or team af die je wensen voor legt. Maar een goed team monitored DMARC leest forensische reports handelt klachten meldingen af richting adverteerder, providers, reputatie issue mediation voor domein en IP, spamfiltering bayes score training en nog heel plethora aan zaken.
Het lijkt me dat dit niet is wat je zoekt of wel?

Unmanaged is peanuts maar je mag zelf alles regelen ongeacht of je nu betaald of niet verwacht weinig hulp en nul maatwerk.

En dan heb je de soort die tussen in hangt waarbij je unmanaged gaat maar support op uur tarief afneemt of op tegoed.


Heb je enkel mail nodig of moeten er ook diensten als calendar (CalDAV) inzitten document readers etc?
Moet er een mogelijkheid inzitten voor import van mail van GMail of nvt of archiveer je?

En encryptie soort belangrijk? AES, PGP, GPG, S/MIME

Kunnen wel dingen uiteraard aanraden op persoonlijke ervaring maar als je wensen niet duidelijk zijn heb je er weinig aan.


Omtrent je nieuwsbrief probleem dat pak je niet effcient aan.
Maak een filter waar unsubscribe in mail text dan auto move to folder X. Zet wat je wel wil ontvangen preventief in je, allow, ignore, whitelist en je bent klaar. Als je goede grip er na een poos op hebt verander je de move to folder naar auto delete.
Klik *nooit* op openen van de nieuwsbrief die je niet wilt of de unsubscribe link tenzij je de partij volledig vertrouwd. En met partij bedoel ik niet het bedrijf waar de nieuwsbrief over gaat maar het bedrijf wat ze inhuren voor hun mailing list diensten als mailchimp, activecampaign, sendgrid etc.

Gebruik voor in de toekomst plus of subadressering en moment dat je niet meer met een dienst te maken wil hebben voeg je het specifieke plus, sub adres in je deny, blacklist. Diensten die niet subadressering honoreren kun je mits je het vanaf begin doet compleet uitsluiten en waar je niet anders kan en met ze moet werken geef je een secundair mail adres op en leg je een filter regel aan waarbij enkel domeinen die je opgeeft op het primaire adres mogen bezorgen.

Plus, sub adressering doet weinig tegen localiseren wie heeft gelekt daar zijn andere methodes voor maar die vergen complete eigen infrastructuur en zijn overdreven voor consumenten dat bestaat uit het gebruiken van de tools van marketeers tegen hun zelf. tracking pixels etc op eigen beheerde autoreplies, click tracking dingen die je hekelt als privacy bewust persoon. Niet de moeite waard zeg ik je alvast en zeer discutabel.

Gaan we nou ook al ruzie maken over wat "managed" is?
"managed" ofwel "beheerd" is een omgeving die je niet zelf hoeft te beheren, dat doet iemand anders voor je.
gmail, hotmail en outlook zijn dus ook "managed" mail omgevingen.

Je hebt hooguit verschillende nivo's van managed, wat betreft garanties en wat betreft implementeren van persoonlijke
wensen. Kun je het spamfilter laten tunen naar jouw behoeften, of krijg je gewoon een standaard botte bijl spamfilter
wat een groot deel van de spam en een merkbaar deel van je gewenste mail wegmikt. Bij grote diensten kun je daar
zelf meestal niets aan aanpassen, met een specifiek voor jou managed service misschien wel.
Maar dat zijn details. Die bepalen niet of het managed is.

https://www.hostingdiscounter.nl/e-mail/e-mail-only

https://www.zoho.com/nl/mail/

TS hier,

hartelijk dank voor de suggesties, ik ga mij hierin verdiepen en zal tzt laten weten welke aanbieder het gaat worden

Heel veel van deze "unsubscribe" links worden ook gebruikt om te checken of je email adres nog actief is, en dan word je hierna op een lijst gezet met actieve email addressen. Deze lijsten worden voor meer verkocht op de zwarte markt dan lijsten met normale/niet gecontrolleerde email addressen. Als je pech hebt krijg je dus daardoor alleen maar meer spam in je email.

Daarnaast zitten er ook vaak "trackingpixels" in de mail, die geladen worden zodra je de afbeeldingen uit de email gaat laden, deze pixels zijn uniek gemaakt voor jouw email adres, waardoor ze dus ook gelijk weten of een email adres nog gebruikt wordt en actief is.

Ik wil niet zeggen dat het bij alle bedrijven zo gaat, maar er hoeft maar 1 tussen te zitten met verkeerde bedoelingen.

Naast tuta en proton, noemt https://www.privacyguides.org/en/email/ ook nog mailbox.org. Die ben ik al een tijdje aan het uitproberen, en heeft een interresante aanpak met betrekking tot spam. Standaard is er namelijk geen "Junk" map, maar sturen ze een "delivery failure notice to the sender". Je kan de spam-folder wel aanzetten in de instellingen, en ook andere parameters van het filter afstemmen naar wens.

Slecht is dat, want dan heb je dat belangrijke mailtje dus niet en moet je weer bij de afzender gaan bedelen...
Dit is de hoofdreden dat ik zelf mijn mail host: ik wil geen mail ongezien laten verdwijnen omdat iemand anders vindt dat het spam is.
Overduidelijke spam mail geeft bij mij wel een failure notice maar evengoed komt het in de Spam map.

Die mailbox zijn hobby hosters en zij ondersteunen niet eens SASL methods zoals CRAM of MD5-DIGEST, alleen maar PLAIN.


Weer iets waar Gmail beter in is en zelfs Outlook.com die wel moderne protocolen ondersteunt bijv je TOTP via MS Authenticator


Zonder 2FA heb je het probleem van guessing/bruteforce attacks die in mijn ervaring als serverowner alleen ophouden bij moderne protocollen

Dingen als username+password over TLS zijn achterhaalde security... Je moet toch authentication protocollen ondersteunen in 2024 via SASL of...

Die Duitsers zijn blijven steken in het jaar 2006, zoals zovelen

Maar vertel me anders maar wat je nog man met OAUTHBEARER, opvolger van o.a. OXAUTH2 wat dan wel iets meer levert....

Protonmail is veel beter , maar slechter dan Gmail op security gebied (mits je snapt dat privacy!=security en mits je de JavaScript AES encryptie van Protonmail niet in consideration neemt etc)

Jammer dat Tutanota geen ESMTP aanbiedt... Wel hebben ze op Android voor de app een eigen Notification implementation, beter dan de Protonmail App , welke via Firebase Cloud Messaging gewoon metadata over jouw inkomende mails lekt naar de Big Tech eyes.....

Goed, in 2018 was dit nog erger , toen lekte zelfs Signal je notificaties "hey Johan.. Vandaag weer kinderen aan het stalken?" via de Google server , GCM voordat ze in 2019 omswitchten naar Firebase Cloud Messaging en de metadata uit zetten via de ingebouwde optie....
... Waardoor tegenwoordig apps als Signal en Protonmail gelukkig geen content, apparaatinfo etc lekken voor elke push notficatie "you have 1 new message" , maar de 13+1 Eyes of the NoSuchAgentur krijgen "slechts" jouw IP door en datum/tijd bij elke notificatie van Signal of Proton... Das dus een hele vooruitgang maar Proton doet het slechter dan Tutanota (om alleen mail apps te vergelijken) echter is Tutanota best wel "proprietary" in de zin van.... Geen ESMTP optie, een boel functionaliteit wat weinig mensen gebruiken en een APK van bijna 60MB (veel code joh) ... Maar goed dan heb je wel "local push notifications".....

Ergo... Geen enkele oplossing is perfect . de enige oplossing is self hosting van alles ....

Begin maar.. Postfix (ik pref Sendmail trouwens) met 2 MXen, SPF, DKIM, DMARC, ESMTP +SASL op TLS1.3 enz

En dan heb ik het nog niet over je servers (2 mxen) bijhouden, patchen, monitoren, email logs checken, error logs smtpd, spam tegenhouden en abuse beheer enz... Heb je een taak aan , bovendien kost het geld....

Je moet je hardware ownen.. Een VPS op iemand anders zijn shared server is een risico, bovendien kunnen de 7 eyes, 12 eyes (666 eyes?) gewoon de VPS hoster dwingen een Snapshot te maken van je mailserver incl configuratie ..... Dus goedkoop is duurkoop

Als je secure email wil, kan allemaal, kost alleen moeite.. Fysieke hardware, fysieke on site security etc

Protonmail en Tuta won't cut it... Je weet niet wie daar achter zitten 100% of the time, en Protonmail kun je in theory, ook in de praktijk -mits privilege- decrypten door een foutje te introduceren in de JavaScript's, bijvoorbeeld door een browserhack , of een geavanceerde MITM attack waarbij de TLS certs genept worden....

Wat is de ideale situatie?

De NSA zouden we willen vertrouwen maar we denken dat er abuse is, dat technische middelen misbruilkt worden om individuelen psychologisch te mindfucken, gaslighten, triggered, treiteren, teneinde geweld o.i. d uit te lokken in een anderszins veilige democratische omgeving, het opzettelijk destabiliseren van mensen onder het mom van pseudo -bijna religieuze- feelgood argumenten , alsof democratie "slechts een spelletje" is.....

Je moet je beschermen tegen misbruik, omdat je niet weet waar het vandaan komt, en waarom.. Of omdat mensen met kennis misbruik van die kennis, en uiteindelijk iedereen meeslepen naar een hel op aarde..
Ben je een beetje integer, verdiep je in de materie, en je komt een heel eind... Ad free, smut free, mind free, geen afleidingen op je scherm etc

Maar goed, je weet niet wat je niet weet he, namelijk:......vul zelf in


Hopelijk word deze lange post op prijs gesteld


Johan

Kun je uitleggen waarom dat van belang is?

Veel grote internetaanbieders hebben TLS en PLAIN.

Inderdaad, dat gaat nergens over. Mail server authenticatie met SASL dat was een slap probeersel om over niet-encrypted verbindingen in te loggen zonder dat iedereen het password kan meelezen. Dit is totaal vervangen door gebruik van SSL, en als je dat hebt dan kun je weer gewoon het password in plaintext sturen. Natuurlijk moet je wel opletten dat je client de geldigheid van het certificaat van de server controleert, dat is niet altijd het geval.

Maar als je de rest van het verhaal leest dan zie je hoe Johan erin staat.

Ik gebruik ook al jaren mijn mail adres en heb gekozen om zelf een mailserver te bouwen met procmail en neomutt en roundcube. Dat gaat goed. Soms loppt ik tegen blokkades aan zoals hotmail.com en icloud.com vanwege reputatie van mijn mailserver, maar dan hebben die pech. Reden om zelf een mail server te beheren is dat ook de mailserver van de provider soms problemen opleverd als deze weer eens op de blacklist staat, in mijn geval ook vanwege reputatie problemen. tegenwoording is niks meer zeker als het gaat om spamfiltering en allerlei andere dingen zoals nu ook kpn veilig dat nieuwe nl domeinnamen blokkeert met KPN Veilig (van fortiguard) vanwege resente registratie ervan. Het wordt steeds gekker ! Ik snap het allemaal wel, maar het wordt echt onwerkbaar !

Er is een RFC waarin dat precies staat beschreven. Ff googelen

CRAM is beter dan plain want versleuteld.

Hetzelfde met md5, maar md5 zit tussen CRAM en PLAIN in.

Als je op een SMTP server inlogt met het EHLO commando , zie je de server opties.

Het is verstandig naast TLS (1.3, of 1.2) voor de verbinding ook een authenticatie protocol gebruikt met gecodeerde hashes geeft dit simpelweg een extra laag van security.

Stel dat TLS wegvalt (geen forced 1.3, of downgrade attack met MiTM, of misconfiguratie bij client/of server) end terugvalt op ouderwets plaintext tcpip traffic , dan heb je met SASL not steeds je password beveiligd maar niet met de PLAIN method....

Dit is tevens mijn reply op de laatste poster

SASL werd later common use dan SSL (tegenwoordig TLS)

Maar je verward TCP encryptieprotocol met een authenticatie protocol, die zijn echt niet inwisselbaar . SASL auth, zelfs Plain method, doet meer dan gewone SMTP Plain method.
Waarbij SMTP gewoon een pass stuurt, zie je bij SASL een paar challenges heen en weer gestuurd , nu ben ik zelf vrij onbekend met SASL en geen expert maar dit lijkt me touch MITM attacks tegen te gaan??

Verder is -denk ik zo- SASL geen oplossing voor SMTP of IMAP specifiek , maar wat ik lees in RFCs is het bedoeld om het hele idee van authentication los te koppelen van app protocols.. Het is meer te vergelijken met Kerberos, NTLM voor active directory enzo

Protocollen als POP3, IMAPv4 enz hebben allemaal een eigen login methods, met SASL ondersteuning is dat gelijkgetrokken en kun je je veiliger authenticaten (challenges en evt hashed passwords) waarbij je eventuele bugs of designfouten in het protocolspecifieke omzeilt.

Hoop dat ik het zo goed begrepen heb, maar mij lijkt zelfs SASL plain (over TLS) veiliger dan TLS login zonder SASL vanwege de challenges.
Misschien dat iemand anders dit kan bevestigden.

Dus je hebt geen toestemming hiervoor vanuit je ISP en bent in contract breuk anders had je niet in een PBL gestaan.
Want je kunt klaarblijkelijk niet IP reputatie issues zelf verhelpen. Wel eigen verantwoordelijkheid maar sta niet gek op te kijken als je straks van het netwerk wordt gedonderd wegens steeds strengere verzend eisen. Eisen waar jij als niet lease houder van de IP range geen controle over hebt.

Als je SASL PLAIN gebruikt zijn er dus geen challenges, bestaat uit 1 bericht van client naar server met het wachtwoord, vervolgens is de gebruiker nadat de server het gecontroleerd heeft geauthenticeerd.

Met je eigen woorden: Er is een RFC waarin dat precies staat beschreven. Ff googelen

Even voor de duidelijkheid: het heen en weer sturen van challenges is geen eigenschap van SASL, maar kan een eigenschap zijn van een gebruikt authenticatie mechanisme onder SASL. Want SASL is het framework, niet een specifiek authenticatie mechanisme.

SASL Plain werkt gewoon met een enkel bericht van client naar server. Het idee achter SASL is om het authenticatie mechanisme van het applicatie protocol los te koppelen.

"een RFC" is veel te vaag. Je zult beter moeten refereren.


Dat is een greeting, geen inlog, maar ik begrijp dat je dan AUTH opties wilt zien.


Ja, maar alleen als je zeker weet met wie je praat. Het is niet zo simpel. Clients gebruiken geen CA certificaat gebonden aan een domeinnaam, dus dat is te onderscheppen als MitM.


Dan ga je er voetstoots van uit dat je weet dat je rechtstreeks met de betreffende server communiceert.

Toch zie ik met de debug optie bij SMTP dat SASL plain challenges doet want mijn provider ondersteunt maar een halve sasl implementatie.
Het heeft ondanks plain dus iets van een extra bescherming.

De rfc had ik vorige week al gelezen toevallig

Precies! @ laatste alinea

Sommigen verwarrren dit omdat ze denken dat SSL/TLS het oplost.

Maar ik zie echt een challenge tussen server en client bij PLAIN method net voor het versturen van het plaintext password. Bij gewone SMTP auth zonder sasl wordt komt er veel sneller een response ala:

Met SASL PLAIN:
Client blabla> server
Server blabla > client
Client password > server
Server > client password OK

Zonder SASL:
Client password > server
Server > client password OK


Even uit mijn hoofd, ik geloof dat er bij sasl plain een hash wordt gegeven aan de client en visa versa , dit is dus niet een md5 password hash want het is de plain method.
Dus er gebeurt toch -iets- meer dan bij auth zonder sasl ...maar ik vraag me werkelijk af of dit dan extra security geeft alleen omwille van het gebruik van SASL (dus of sasl zelfs met plain echt meerwaarde is t.o.v. smtp plain zonder sasl)

Misschien moet ik me er eens wat dieper op storten , wel interessante materie namelijk.

Wat bedoel je precies met "Zonder SASL". Er bestaat geen standaard authenticatie mechanisme in het SMTP protocol, als je je authenticeert met een SMTP server gebruik je een SASL mechanisme.

Korte update:

SASL PLAIN = ascii text
SASL LOGIN = base64 encoded text
SASL CRAM en DIGEST = md5 of sterker

Dus hierboven zou dan base64 moeten zijn , wat an sich geen veiligheid biedt maar de vraag is of de LOGIN methode via SASL dan toch beter is dan gewoon SMTP'en zonder SASL ...... experts? :)

Nee.

>SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. <

Er bestaat SMTP AUTH

En als je MUA met SASL wilt gebruiken moet je je MUA tegen _optionele_ SASL libs compileren.

Als je dat doet heb je dus deze opties:

SMTP AUTH
SASL PLAIN
SASL LOGIN
SASL DIGEST(MD5)
SASL CRAM

(van zwak naar sterk)

Maar ik vraag mij dan af wat het voordeel zal zijn van SASL LOGIN vs SMTP AUTH (beide over TLS)

eerlijk gezegd, heb ik me hier ook nooit eerder in verdiept en gebruikte ik blijkbaar altijd gewoon SMTP AUTH via TLS/SSL

Ik heb zonet een MUA met SASL uitgerust tijdens compiletime en zie meteen bovenstaande extras, maar helaas biedt de provider een halve SASL implementatie aan, namelijk alleen PLAIN en LOGIN (=base64). Ik vraag me dan echt af wat hiervan de meerwaarde is , en misschien heeft deze ISP zich ook niet echt verder verdiept in authenticatie, ze draaien Postfix en weten dat te configgen maar verder niet

Iemand zou mij eens moeten uitleggen waarom een hoster dan Postfix gebruikt, met SASL maar dan alleen Plain/Login (base64).
Is dit vanwege dat SASL met MD5 dan eist dat de server een database met md5 hashes moet hebben? Dat ze Digest er maar uitslopen?

Want waarom zou je dan als hosted/serverowner nog Sasl gebruiken, terwijl die Cyrus Sasl libraries best wel veel extra code (en bugs) toevoegen aan je server...waardoor je Postfix opeens net zo secure wordt als bijv Dovecot met Cyrus Sasl??

Er zijn dus argumenten voor en tegen Sasl gebruik op Postfix maar de argumenten voor, met Login/Plain methodes zijn wel erg dun en wegen niet op tegen de enorme hoeveelheid lines code aan de serverkant...

Maar als die code toch al server side draait.. Maakt het dan uit wat de client doet (SMTP Auth vs SASL auth) ..? Dat is een subtiele technische vraag voor experten... En heeft SASL Login method meerwaarde t.av. SMTP basic auth ....?

SMTP AUTH is zelf geen authenticatie mechanisme. Het is een extensie van het SMTP protocol om het mogelijk te maken een (ander) authenticatie mechanisme te gebruiken binnen het protocol.

Hallo mede security-isten (ik reageer op diverse besproeken items maar hoofdzakelijk op de z.g. pbl dictatuur, zie quote)

Je kunt altijd prima pbl/rbl listings zelf managen, of dit nu je eigen ip is of van een provider. Lukt dit niet voor de ene vorm van ip nummer lukt dat zeker ook niet voor de ander. Er waren/zijn rbls die gewoon betaald wilden worden voor een de-listing. Hoe populairder ze werden hoe duurder. Deze partijen zijn eigenlijk nu niet meer zo prominent in de markt door de cloud mail graaiers die iedereen laten denken dat je niet betrouwbaar zelf kunt hosten o.a. rbl problematiek. Wat dus wel degelijk kan. Maar ook zoals eerder gemeld er zit een learn curve aan.

Wil je geen last hebben van pbl/rbl listen hebben of dat deze genegeerd worden dan moet je mail-server zich fatsoenlijk identificeren.

Doe dat met de eerder genoemde technieken c.q. dkim, dan heb je daar geen last meer van omdat je certificaat leidend word ipv je ip nummer.

Deze certificaten hebben helemaal niets te maken met het encrypten van mail maar alleen van identificatie van je mail-server/cluster.
Zelfs de gmail cloud accepteert mail van een block listed ip die fatsoenlijk beheerd is.

Aha.. Maar hoe wordt er dan bij bijv Postfix authenticated , als de client geen SASL gebruikt omdat deze simpelweg niet in de MUA is meegecompiled?

Want de client stuurt dan toch een username en password naar de SMTP server, debug logs zeggen "smtp auth" wat verandert in Sasl zodra die library mee compiled wordt.

Als de client zonder sasl toch kan inloggen , is er toch een authenticatie method (SMTP auth?) of misschien wat anders maar laat de server dit niet zien , misschien dat de backend wel Radius of Krb5 gebruikt maar dit niet aan de client doorgeeft.... Bedoel je dat?

Het gaat er niet om hoe vaardig jij zelf bent, maar hoe discriminerend de lijst bijhouder is.
Je eigen IP is uiteraard schoon want je stuurt geen spam. Even aangenomen dat je een vast IP hebt is er geen reden je te listen.
Maar spamlijst managers willen nogal eens methoden hanteren die we in het normale leven racistisch of discriminerend wouden noemen: op basis van generieke kenmerken zoals "jij komt uit die buurt" word je gelist.
Daar valt niet tegen te vechten, hoeveel kennis je ook hebt, net zoals je persoonlijk niet kunt strijden tegen racisme.
Dat zou je hooguit via een aangifte kunnen doen en dan de rechter het laten toetsen.

> SMTP AUTH is zelf geen authenticatie mechanisme. Het is een extensie van het SMTP protocol om het mogelijk te maken een (ander) authenticatie mechanisme te gebruiken binnen het protocol.

Ik denk dat ik je snap.

Het daadwerkelijke mechanisme server side kan alles zijn van Radius tot Kerberos tot Sasl en Active Directory enz
SMTP auth zit daartussen...

De client ziet alleen "SMTP auth" in logs want die hoeft niets te weten over de server back end...

Tenzij ik cyrussasl meecompile in de MUA/client, dan verandert de client side melding van 'smtp auth' naar 'sasl login'.

De rest is semantics lijkt me?

Maar inderdaad SMTP auth is niet de methode zelf, alleen een afspraak tussen client en server voor het doorgeven van credentials (plaintext).

Toch leek mij libsasl meer secure, zelfs met de Sasl Login method (=base64) alleen omdat de server dan een extra regeltje data met de client uitwisselde, maar ja het is niet bepaald secure want base64 is gewoon plaintext , en ook al is de authenticatie met sasl-login iets langer dan smtp-plain , het meecompilen van Cyrus Sasl vergroot de attack surface van zowel client als server... Dus het vermeende voordeel heeft ook een nadeel.

Ik denk dat ik Sasl zou kunnen overwegen als de ISP CRAM of Digest accepteerde, maar helaas is dit niet het geval en kan ik alleen Plain/Login(base64) gebruiken als Sasl auth methode.. Dus vermoedelijk ben ik veiliger zonder sasl (attack surface!) door gewoon de standaard SMTP authenticatie te gebruiken.. Correct me if I'm wrong

De reden waarom de ISP geen md5/cram support is vermoedelijk omdat ze dan een extra database moeten bijhouden met md5 hashes, bijv als hun primaire login database bijv SHA hashes zijn, ofzo
Maar dit is een vermoeden

Hmm, ik zou ook wel eens willen weten of SASL (Login/Plain) op de SMTP server een security voordeel heeft of niet.

Er zullen vast wel mensen op dit forum lezen met verstand van mailservers.

Niemand ?

Als je een vast IP hebt dan heb je tegenwoordig bijna altijd een zakelijk contract en daar staat in vast wat je wel en niet mag doen op het IP zakelijk wil niet meteen zeggen dat je ook even een mail server mag hosten daar heb je toestemming voor nodig.

Maar los daarvan dan nog moet de uitgever van het IP het datacenter de PBL uitzondering behandelen dat kun jezelf niet want jij staat niet als de eerste lease houder opgegeven die controle gebeurt via het controleren van de autonomous system (AS) nummer. En als dat nummer niet uitkomt op jou als network owner en je staat tevens niet ingeschreven bi de PBL als ISP dan hele grote kans dat je aanvraag linea recta de prullenbak ingaat.

Als we het hebben over een dynamisch IP en dan specifiek IPv4 dat zit je met Carrier-grade NAT (CGNAT) en dus nog paar honderd gebruikers op zelfde IP en dat is de reden waarom dynamische IP's in de PBL staan opgenomen want dat is alleen maar gezeik voor providers. En nee je kan dan dus geen uitzondering maken want dan heb je misschien 1% competent dat je doorlaat en 99% buffoons. Dus nee je eigen IP is vaak helemaal niet schoon want je hebt geen enkele mogelijkheid te zien als consument lease wat er over dat IP is gestuurd enkel wat er via jouw netwerk over het gezamenlijke IP gaat.

Range blocks (meestal een /24 Classless Inter-Domain Routing (CIDR IPv4 of /48 IPv6) ) waar je naar verwijst wil zeggen dat de provider de boel niet op orde heeft. Niks met wat je onder racisme of discriminatie kan plaatsen gewoon onkunde waarbij een andere partij zegt van deze provider vormt een gevaar met deze range en tot ze het oplossen zetten we ze in een blocklist of activeren throttling, greylisting.

En dit type blocks wordt bij de meeste providers niet lichtzinnig over gedaan omdat het hele grote consequenties heeft. Maar helaas soms is het nodig. Providers moeten zorgen dat hun klanten geen illegale praktijken verrichten en ook niet kwetsbare omgevingen onbeheerd laten staan.

En daar kan absoluut wel wat aan doen namelijk je provider aansprakelijk stellen zorgen dat ze hun IP reputatie management bijhouden. Maar dan hebben we het wel over situaties waar je dus wel recht uberhaubt moet hebben op eigen mail server gebruik. En doet je provider niks er aan of te langzaam dan is het eigen verantwoordelijkheid om een andere te zoeken die wel competent is.

Verwacht echter niet veel van de mainstream consumenten providers hierin. Die roteren namelijk gewoon hun mailserver clusters en sturen een verzoekje in als het uitkomt. Mailtje niet gelukt pech nog maar keer sturen en hopen dat het nu via nieuwe cluster gaat.

Weer het bekende goedpraten van discriminatie. Jij krijgt hier geen baan want je woont in Overvecht, had je maar moeten zorgen dat de burgemeester regelde er niet zo veel criminelen in Overvecht wonen.
Misselijkmakend is het! Je snapt niet dat er niet tegen die lists wordt opgetreden.

https://www.startpage.com/do/dsearch?query=SASL+SMTP+server

De vraagsteller hier.

Dit vind ik nou zooo dom als iemand dit post. Dingen als 'google is your friend'... Wat denk je , dat ik zelf niet de moeite heb gedaan iets op te zoeken? :)

Ik heb 2 RFCs volledig uitgelezen;
Heb meerdere sites die erover praten bekeken - geen antwoord;
Heb Superuser (de website) en Reddit subs nageplozen;
Heb via duckduckgo (dus niet google:) gezocht op meerdere combinaties, meerdere dagen achteraan;
Heb vragen gesteld hierover bij de specialistische isp--geen antwoord;
Heb 2 dagen SMTP clients lopen hercompilen met/zonder Libsasl en SMTP debug logs gemonitored;
Heb meerdere (lange) posts hier in deze thread gepost... Omdat ik dus geen antwoord heb op de hierboven gestelde vragen.

En blijkbaar lees er ook niemand hier momenteel met de tech know how over dit specifieke protocolvraagstuk.

Ik ben dus op zoek naar kennis... Niet naar een quote van wikipedia over semantiek zoals hierboven al eerder werd geopperd.

Specifiek dus wil ik (nog steeds) weten, hopende dat een kundig iemand mij kan helpen aan een antwoord of:

- wat is veiliger? (Voor de client)
1. SMTP (over TLS) met standaard authenticatie (postfix implementatie); of
2. SMTP (over TLS) met CyrusSASL lib , met Plain of "Login" (base64) authentication ?

Voor de goede orde: de ISP support alleen Plain/Login bij SASL en niet CRAM/Digest . Waarschijnlijk omdat de ISP dan een extra database table moet bijhouden met andere hashes dan de etc/shadow file.

Dus de vraag: het is allebei dus plaintext over TLS , welke *authenticatievorm* is meer secure: zonder SASL of met SASL?

Er van uit gaande dat Cyrus libSASL ook weer extra attack surface is....

En indien het antwoord 'zonder SASL is veiliger' is, dan is mijn tweede vraag of een SASL auth met CRAM of Digest dan weer veiliger is dan SMTP auth zonder SASL.


Het is dus een specifieke vraag die iemand met verstand heeft van mailservers en security.... Aangezien dit een security forum is hoop ik hier slimme antwoorden te vinden.

Helaas heeft googelen mij niks opgeleverd...

Dan ff wat anders:

Wat mij ook opvalt is de grote hoeveelheid onkunde op internet, zelfs bij zgn specialisten op een (ander) onderwerp zoals poort 587 (explicit tls) boven poort 465 (implicit TLS) gebruiken. Bijna iedereen in de mailserver industrie heeft het onjuist, ze zijn in de veronderstelling dat STARTTLS op poort 587 the way to go is en 465 deprecated is.

De recommendaties van het IETF zijn alweer reversed in 2019. Staat in de geupdated RFCs. Poort 465 ofwel implicit TLS is nu de beste methode voor een secure SMTP link, want implicit TLS ,checkt aan het begin van de TCP verbinding voor een TLS verbinding (dit kan ook vaak enforced worden vanuit de client config, bijvoorbeeld: TLS 1.2/1.3 only)
Terwijl poort 587 (Starttls) kan terugvallen op plaintext door een packet injection of MITM attack , waardoor je ook iemands username en password zou kunnen achterhalen (en dus al zijn mail meelezen indien zijn IMAP dezelfde is als SMTP login)

587 is explicit TLS . je begint plaintext en waardeert de verbinding dan op naar TLS, evt met fallback naar plaintext.
465 is implicit TLS, dus altijd versleuteld.. Dus altijd beter. En dat realiseert de IETF ook in 2019 toen ze de RFCs updaten , terwijl ze eerder 10 jaar hebben geroepen dat 576 boven 465 verkozen moest worden , maar dat was gebaseerd op:

1) het feit dat de 1999 implementatie van 465 SSL was , en Starttls op 587 was inderdaad een verbetering-- maar inmiddels is alle SSL ook TLS;
2) oude security inzichten in een veranderende wereld; waar vroeger compatibiliteit de grootste rol speelt, is nu een "altijd encrypted TCP stream" veel belangrijker

Een hoop verwarring dus, maar je zult zien dat zelfs SMTP specialisten denken dat poort 587 de allerbeste aanbevolen keuze is (dat was het dus tot 2019)

Zomaar wat info tussendoor, voor wie er wat aan heeft..

@Vandaag, 17:38 door Anoniem

Het afdwingen van TLS kan inderdaad via poort 465, die spreekt alleen SSL/TLS. Dat is gunstig in theorie omdat er geen weg omheen is, en dat encryptie gegarandeerd is. Het probleem is wel dat MitM aanvallen mogelijk zijn. Dat is vooral zo omdat clients geen op certificaten gebaseerde authenticatie hebben. De encryptie blijft opportunistisch. Ook een server kan een zelf gegenereerd certificaat gebruiken, en een MitM aanvaller kan er gewoon een aanmaken, ongeacht het type certificaat de doelserver zelf zou gebruiken.

Als je via DNS en DNSSEC zou kunnen opvragen welk certificaat wel geldig is voor de doelserver is dat te vermijden. Dat kan via DANE.

Maar helaas, het grootste deel van de mail servers dwingen niets af, mede omdat er nogal veel slecht geconfigureerde en onderhouden mail servers zijn, en ook omdat grote partijen zoals Microsoft geen zin in DNSSEC en DANE hadden.

Het beste zou zijn als er een RFC komt die geldige certificaten voorschrijft en een wijze van controle verplicht maakt zodat MitM aanvallen niet zo makkelijk meer zijn.

Het gebruik van TLS of een bepaalde poort is dus niet het grootste probleem. Het grootste probleem is de serverconfiguratie. Die moet op termijn verplicht worden, internet-breed. Wel opvallend dat vooral de grote Amerikaanse partijen er niet in mee gingen en in Europa (Duitsland, Nederland) men wel wil, maar Europese gebruikers clueless zijn en toch gaan voor Amerikaanse aanbieders.

Is dat wel racistisch of discriminerend ?

Verzekeringen doen namelijk hetzelfde, als je uit een bepaalde postcode gebied komt, kan je extra moeten betalen, of betalingsbedrijven kijken hier naar, voor het risico bij kopen op krediet.

Wat als je client, bijv neomutt (wordt dat nog gebruikt?) instelt forced-TLS, met als optie minimal TLS versie 1.2, en evt handmatig de certificaten specificeerd?

Mensen die een IP range krijgen van hun ISP zijn altijd local met IMAP/SMTP maar wie over internet connect met een mailserver loopt altijd risico, denk ik, om de reden die jij aangeeft.

Dus wil men veilige SMTP hebben is het zelf hardcoded configgen van een servercert op de client een must, of is dit paranoia?

Dit gaat verder dan een andere security optie in neomutt, het rejecten van 'ongeldige certs'.


Goed idee, het is vast een kwestie van tijd voordat anderen dit ook inzien.


Eens.

Misschien kan de NSA een paar advisories de wereld in slingeren. Zij hebben er ook baat bij dat Amerikaanse bedrijven veiliger zijn op cyber... Af en toe komt de NSA (waarschijnlijk omdat die 3 letters in die combi wat meer aandacht trekken van lezers)/met een "simpel advies" , wat de doorgewinterde ITsec al jaren doet maar eigenlijk een algemeen goed gebruik is, zoals vorig jaar: het advies elke nacht je router te rebooten als preventieve maatregel. (Iets met Fortinet en China geloof ik...)

Doen ze weer eens wat nuttigs;)

@boven

Postfix is veiliger zonder SASL (attack surface)
Wel over SSL/TLS


Postfix gebruikt saslauthd , en die kan by default geen DIGEST MD5 of CRAM MD5 aan. Dan zou je AuxpropPlugin erbij moeten gebruiken.

Dus is SMTP/TLS zonder SASL veiliger dan met SASL/Plaintext? Ja vast. Maar zodra je server side AuxpropPlugin (voor Digest md5) gaat gebruiken boven op saslauthd , dan kun je weer opnieuw vragen wat veiliger is... Het is allemaal afwegen , servercomplexiteit meerekenen enz

Gebruik je geen SASL en wil je Postfix iets meer secure hebben? Zet het dan uit (attack surface).

Eigenlijk is SASL bij Postfix geen security feat maar een compatibility feat voor integratie met andere diensten bij een ISP , bijv over LDAP


@ andere persoon

Ja, Implicit TLS dus SMTP poort 465 is the way to go.
Want Explicit TLS (STARTTLS) via poort 587 kun je makkelijk hacken:
- men zet er een mitm server neer met TLS disabled, en jouw client gaat dan vanzelf in compatibility mode praten met de server, plaintext dus
Zo hoeft een aanvaller niet eens te klungelen met certificaten ...

Het is dus heel easy (voor iemand op hetzelfde net) om al jouw email verkeer te monitoren als je SMTP poort 587 (submission) gebruikt.

99% van de ITers denkt dat dit de juiste configuratie is :-) en je provider zich maar afvragen waarom je 2x per minuut de pop3s mailbox checkt :)


Stay autonomous!

Diverse Unix MUAs hebben wel zeker een op certificate gebaseerde authenticatie mogelijkheid.

Als ik connect met de SMTP server, wordt het cert getoond met de vraag of ik deze weiger, eenmalig accepteer of vertrouw.

Dus wijzigt de serverconfig, zal ik een certificaatfout zien.
Zo weet ik zeker dat niemand op mijn WiFi (of bij mijn uplink) mijn SMTP traffic probeert te downgraden, en o.a. mijn POP3S pass steelt.


Vriendelijke groet, ..

Stay autonomous!

Precies, er wordt in dit topic heel veel door elkaar gehaald!
Er is een enorm verschil tussen het aanleveren van mail vanuit een user agent en het doorsturen van mail tussen 2 servers.
Dat eerste vereist meestal authenticatie (omdat je niet van willekeurige punten mail wilt aanpakken) en dat gebeurt dan met een van die beschreven methoden, en dat kan over TLS gedaan worden om plaintext wachtwoorden af te schermen.
Daarbij zal het aanleverende programma meestal de mogelijkheid hebben het certificaat te valideren of zelfs te pinnen.
Helemaal los daarvan staat het sturen van mail met een TLS verbinding tussen 2 servers. Inderdaad wordt daarbij vaak het certificaat niet gecontroleerd omdat er zoveel servers zijn die self-signed of verlopen certificaten hebben. Je kunt wel configureren dat het certificaat gechecked moet worden maar dan loop je tegen veel werk aan om uitzonderingen toe te voegen. Echter, bij dit gebruik wordt er ook geen authenticatie informatie gebruikt! De TLS is alleen om meekijken met de mail te voorkomen.
Als je echt beveiligd wilt mailen is dit sowieso al geen oplossing, omdat het alleen het transport beveiligt. De mail staat op de servers gewoon in plaintext op de disks. Wil je dat niet dan moet je in de MUA encrypten (S/MIME of PGP).

@Gisteren, 18:09 door Anoniem

De meest gebruikte mailprogramma's tonen geen certificaten of alleen als er duidelijk iets niet klopt (domain/ip
mismatch). Gebruikers kun je niet belasten met zo'n taak.

@Gisteren, 19:55 door Anoniem

Als man-in-the-middle kun je certificaten vervangen, zelfs door self-signed. Dat is een zwakte. Je weet als client meestal niet zeker met wie je praat, tenzij je zelf de mail server beheert en een certificaat krijgt te zien, en dat is uitzonderlijk. Als man-in-the-middle kunnen wachtwoorden worden onderschept.

De oplossing is dat servers moet kunnen worden geauthenticeerd door clients en door andere mail servers.

Ja, dit, en 90% van de normies zitten op gmail want email is gmail en google is het internet :-)

Email binnen EU of van Nederlandse servers naar Nederlandse / lokale recipients (ook binnen de infrastructure) die genieten wel bescherming tegen meelezen door internationale sniffers. Maar helaas wordt steeds meer cloud based, dus internationaal uitbesteed met een .nl suffix om het lokaal te doen lijken.

S/MIME moet ik eens bekijken.. PGP ken ik uiteraard wel.

Weet jij of verkeer tussen servers onderling altijd over TLS gaan tegenwoordig (al is het zonder cert checks)?

Ik weet nog dat vroeger alles via poort 25 ging. Die zal nog wel door enkele servers gebruikt worden helaas.

En de gespecialiseerde gebruiker? Die wel bij de eerste use een ISP cert accepteert, en vanaf die dag merkt wanneer dat cert verandert... Lijkt me dat hij toch wel zeker weet dat hij met de ISP praat , toch..

Klopt dat de meeste clients geen cert warnings tonen, of de opties zijn verstopt want dit zijn geavanceerde instellingen naar het schijnt:)

We weten allemaal wat er gebeurt als er ineens nuttige waarschuwingen in beeld komen bij ook leken. support ticket aanvragen naar providers. En dat willen ze niet dus dat komt er niet in. Mijn omgeving toont of het TLS actief staat en overeenkomt met de genoemde partij en apparte waarschuwing als het dmarc, spf problemen geeft. Maar dat is een betaald zakelijk platform.

De regel is algemeen als je als niet leek iets voormekaar wil krijgen dan ben je duurder uit want je bent de uitzondering op de markt en dus niet rendabel.

Als jouw domain DMARC just heeft ingesteld dan krijg je vanzelf email reportsn wanneer er iets mis gaat, of bij spoofmail, maar dan moet je of SPF of DKIM hebben, of beide


Ik weet alleen niet of je DMARC reports krijgt als je p=none in je config hebt staan , zoals bij security.nl, want dit is geen enforced dmarc policy....dus of het in die setting zin heeft?

Mij lijkt een DMARC policy met p=none optie , wat security.nl heeft, lijkt me vrij zinloos .. Ik zou p=reject kiezen :)

Correct. De mailclient die de meeste settings hiervoor heeft - bij mijn weten - is FairEmail (Android). Die kun je zelfs instellen dat ie de DNSSEC/DANE records checkt alvorens het verbinden met de mailserver (MDA).

De meeste MTA's ondersteunen DANE overigens vrij goed - maar het is jammer dat de clients (MUA's) het vrijwel niet doen.