STRATO e-mail via GMail "Aanval op je STRATO account"?

[grasmanek94]

Ik heb een e-mail postvak bij strato.
De mail laat ik in Google ophalen via GMail.com -> Instellingen -> Externe accounts.

Vanochtend deze prachtige mail gekregen:


IP gecheckt, lijkt van Google te zijn.
Neem ik een kijkje, en ja hoor, GMail kan geen berichten ophalen



STRATO heeft dus gewoon Google geblokkeerd.

Geen wachtwoorden oid recent gewijzigd.

Mijn hypothese is dat er bij Google gewoon veel strato gebruikers zijn die doen wat ik doe, en daarvan heeft een aantal misschien verkeerde wachtwoorden, die dus een soort van beveiliging hebben laten triggeren... of omdat Google zoveel mail ophaalt bij Strato, zijn er gewoon beveiligingen af gegaan (recent iets aangepast bij Strato?).

Zijn er anderen met dit issue?

Dat wachtwoord is overigens alleen bij Google bekend, gezien ik voor alles een apart wachtwoord in mijn password manager heb. Mocht dat wachtwoord daadwerkelijk ergens anders gebruikt worden dan zou of mijn password manager database en master key gelekt zijn, of Google zou een lek hebben, maar ik betwijfel sterk dat hier sprake van is.

Wat ik wel kan zien in de password manager, is dat dit wachtwoord zeker niet makkelijk te raden kan zijn (zoals ze proberen te beweren in de mail).

Met de telefonische klantenservice kom ik niet verder dan "Meneer u moet een antivirus scan op uw computer doen, en uw wachtwoord wijzigen"
Op mijn thuis adres kan ik gewoon prima inloggen met die mail + wachtwoord, dus dat geeft alleen meer gewicht aan "Google is door Strato geblokkeerd".

[ Voor 12% gewijzigd door grasmanek94 op 21-03-2024 12:02 ]

[GarBaGe]

Als je van Strato geen Gmail mag gebruiken, dan is het OF Strato de deur uit OF Gmail de deur uit.

[internet4me]

Grappig dat er nog steeds mensen zijn. Die liever discussiëren over een fout bij de leverancier ipv reageren op een mogelijke wachtwoord lek.

Altijd -ALTIJD- bij een vermoeden van een wachtwoord lek. Zelf je wachtwoord wijzigen en daarna uitzoeken van hoe en wat.

Verder. Pop3 is niet veilig. Stop daar mee. Als het niet anders kan…..neem je afscheid van deze leverancier.

[grasmanek94]

Opeens lukt mail ophalen, dus misschien hebben ze bij Strato wel meer meldingen gekregen.
En qua POP, je bedoelt dat ik weg moet bij Google? Tja zou kunnen, maar daar aan gewend.
Bij GMail settings kan er alleen POP worden opgegeven, wel via beveiligde poort 995 (TLS/SSL), niet 110.
Kan dus vergeleken worden met HTTPS vs HTTP, niemand zegt toch dat HTTPS onveilig is?
Overdrijven is ook een kunst mensen.

Maar terug naar de originele vraag: komt dit vaker bij anderen voor, of is dit pas iets recents? In de 10 jaar dat ik er zit is dit de 1e keer. Als dit vaker voor gaat komen, dan misschien beter om mail te migreren naar een andere hosting ja.

[ Voor 36% gewijzigd door grasmanek94 op 21-03-2024 12:14 ]

[GarBaGe]

Ik heb met Strato geen ervaring.
Ik ken wel iemand met Antagonist en vergelijkbare constructie naar Gmail van Google.
Daar zijn nog nooit problemen mee geweest.

[joostgvr]

Ik heb ook mail van Strato wat ik binnenhaal op Gmail. Ik heb geen mailtjes van Strato ontvangen, dus het is niet een breed iets.

[unixa]

Ik heb vandaag om 13.18 dezelfde email gekregen en ik haal ook mijn email op via Gmail.

code:

Land van toegang: IE
IP-adres: 2a00:1450:4864:20:770f::

Wachtwoord onderhand gewijzigd, maar oude wachtwoord was erg uniek, veel te lang en te onvoorspelbaar om iets mee te kunnen. Kan Strato helaas niet gewoon via ticket of chat meer bereiken. Bellen kan wel.

[peter-pi]

Ik heb vandaag 2x mail mogen ontvangen. Eentje voor elk domain dat ik heb bij strato.
Veiligheidshalve de ww gewijzigd, maar de IP check resulteerde 2x in google ip's (US & IE)
Maar inderdaad, strato blijft gmail blokkeren lijkt het, want ook ik blijf aanlopen tegen een AUTH error.
Ik heb hierover nog niemand te pakken gekregen bij Strato. Maar @grasmanek94 , je bent dus zeker niet alleen.

edit: Eerst even opnieuw ingelogd op de webmail bij strato. Nadien een nieuwe poging bij Gmail gedaan en plots werkt het weer.

[ Voor 28% gewijzigd door peter-pi op 21-03-2024 17:49 . Reden: Nieuwe info ]

[basvn]

Hier ook mailtjes ontvangen van verschillende emailaccounts die in Gmail gekoppeld zijn.
9.37 hebben mijn ouders mail gekregen. Ik net om 21.14 voor mijn eigen domein

Alles heeft een uniek en lang wachtwoord

[ Voor 11% gewijzigd door basvn op 21-03-2024 21:40 ]

[joostgvr]

Inmiddels een dag later heb ik vanochtend om 4:54 ook een mail van Strato gehad met dezelfde strekking.
Edit:
data toegevoegd
Datum en tijd: 22.03.2024 01:56:19
Gebruikt protocol: POP3
Land van toegang: IE
IP-adres: 2a00:1450:4864:20:790f::

[ Voor 41% gewijzigd door joostgvr op 22-03-2024 13:47 . Reden: gegevens uit de mail van strato toegevoegd ]

[MasterL]

Oke even analyseren, er zijn in dit topic twee (V6) IP-adressen gepost beide van Google (source RIPE).
Als veel mensen gebruik maken van deze POP/IMAP dienst komen er dus veel requests van bepaalde (lees Google) IP-adressen. Men geeft uitteraard credentials op zodat de mailbox gepulled kan worden.
Strato (ids/ips?) detecteert veel (geslaagde) login pogingen op een relatief onveilig protocol vanaf bepaalde IP-adressen waarna deze IP-adressen worden geblacklist. Tja is je account gehacked in dit hypothetische verhaal? Nee je hebt de credentials zelf op gegeven. Is het logisch dat Strato de IP-adressen (tijdelijk) blokkeert? Ja! veel requests van een bepaald IP-adres zijn nou eenmaal verdacht en lijkt vanuit security oogpunt op een brute-force.

Zou Strato kunnen anticiperen op de Google IP-adressen? Ja maar dan moet er wel (handmatig) een whitelist van IP-adressen worden bijgehouden. POP/IMAP connectors heb ik in het bedrijfsleven echt al 10-15 jaar niet meer gezien en is ook gewoon een waardeloze oplossing. Als jij je mail wil hosten op een andere plek regel dit dan fatsoenlijk dus:
1: Domain/mailbox met de juiste accepted/domains.
2: MX records naar de server die daadwerkelijk je maibox host.

[grasmanek94]

Ik ga ze een webformulier contact verzoek sturen met de link naar dit topic, misschien dat het dan naar de technische dienst gaat.

Is lastig te vinden, moest 't via (hah) Google doen; https://www.strato.nl/faq/help/mail.php?thema=158

STRATO zou gewoon TXT _spf.google.com moeten whitelisten (of op zijn minst koppelen aan per-account security, en niet per-ip security):

code:

>>>nslookup -q=TXT _spf.google.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
_spf.google.com text =

        "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

>>>nslookup -q=TXT _netblocks.google.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
_netblocks.google.com   text =

        "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

>>>nslookup -q=TXT _netblocks2.google.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
_netblocks2.google.com  text =

        "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

>>>nslookup -q=TXT _netblocks3.google.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
_netblocks3.google.com  text =

        "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

>>>

De genoemde IP adressen zijn in de netmasks aanwezig:

"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

Dus een grote klus is het absoluut niet, Google helpt hier erg door zelf hun IP's te publiceren.

[ Voor 81% gewijzigd door grasmanek94 op 22-03-2024 13:33 ]

[MasterL]

Haha je snapt dat een SPF record Sender Policy Framework, de naam zegt het al (sender,uitgaand/relay)
hier werkelijk niks mee te maken heeft? Als ik dit zou lezen als Strato support zou ik shift-delete doen, een bakkie koffie pakken en verder gaan met mijn dag. Even fyi ik heb geen connecties met Strato, ik werk er niet en ben er ook geen klant maar we moeten wel realistisch blijven.

[grasmanek94]

MasterL schreef op vrijdag 22 maart 2024 @ 12:49:
Haha je snapt dat een SPF record Sender Policy Framework, de naam zegt het al (sender,uitgaand/relay)
hier werkelijk niks mee te maken heeft? Als ik dit zou lezen als Strato support zou ik shift-delete doen, een bakkie koffie pakken en verder gaan met mijn dag. Even fyi ik heb geen connecties met Strato, ik werk er niet en ben er ook geen klant maar we moeten wel realistisch blijven.

Dat het er niks meet te maken heeft is puur vanuit het definitief aspect. Prima als jij vanuit daar reageert, maar ga niet de realiteit negeren als het zijn wel dezelfde servers (of servers op hetzelfde netwerk blok) zijn. Ik weet niet zozeer wat je probeert te bereiken, dat is mij erg onduidelijk, en je gedrag komt gewoon troll-achtig over. Als je wilt laten zien hoeveel technische definities van e-mail en netwerking je bekend zijn, is dit niet het topic daarvoor. Verder ben je wel heel kortzichtig bezig, niet alles wordt puur gebruikt voor de technische definitie ervan, maar afijn.. en corrigeer even je "relatief onveilige" naar "gewoon veilig", want IMAP over TLS is gewoon veilig, dat is zo'n beetje uitgediscussieerd, tenzij je niet TLS gebruikt (Strato verplicht TLS). Dus geen onwaarheden spuwen. Of je leeft onder een steen, want poort 110 komt uit het dinosaurustijdperk, en ik betwijfel dat een service die respect heeft voor zichzelf en klanten, dit nog aanbied.

Ik ben bekend met e-mail security, authenticatie, verificatie, signing, enzv. Idem de netwerk en DNS kant wat dit issue betreft.
De servers die het ophalen hoeven niet dezelfde te zijn als servers die versturen - prima -, dat ze beide in die blokken vallen zal echt geen toeval zijn.


Makkelijkste wat STRATO kan doen is gewoon per-account security policies hebben, en het ip aspect weg laten vallen, maar dat is ook verre van de beste en veiligste oplossing. Een ding wat ik durf te zeggen naar aanleiding van anderen die dit mee maken, is dat het zeker niet mijn account is waarop gebruteforced is, integendeel, er is helemaal geen foute inlogpoging ondernomen voor mijn account vermoed ik.

[ Voor 55% gewijzigd door grasmanek94 op 22-03-2024 13:37 ]

[ajaalbers]

Ik heb dezelfde email gekregen en krijg ook foutmelding in GMail bij het ophalen van mijn strato-email via pop3.
Gisteren de help-desk gebeld en die raden aan om the pop3 server aan te passen van strato.com naar strato.de

Dat hielp even, maar de authenticatie fouten zijn vandaag weer terug

[MasterL]

Erg kinderachtig om steeds je post te wijzigen n.a.v. opmerkingen om je gelijk te halen.
Ik denk dat Strato gewoon de IP-adressen blokkeert waarvan veel request komen en terecht want dat is namelijk "abnormaal". Strato bied een simpele mail dienst aan (waarschijnlijk gekoppeld aan een domein) waarvan het idee is dat er misschien 10x per dag een request komt van een mail client op een pc'tje of mobieltje. Weet jij hoevaak Google polled? 1x per uur, per minuut, per seconde, per milliseconde?

Ook al de aanname dat het dezelfde IP-adresses zijn of hetzelfde subnet..nattevingerwerk.
De "realiteit" is dat als je met wat grotere netwerken werkt dat je services onderverdeelt:
Spamfilters (incoming mail servers).
Mailservers met een mailbox role (Echange term).
Relay/outgoing mail servers.
Web/frontend service voor communicatie met de "clients".

En nee dit hoeft totaal niet in hetzelfde subnet te zitten, kan wel misschien. Maar dan nog? Ga je Strato vragen c.q. verplichten om een uitzondering te maken voor Google omdat bepaalde klanten hun mail vanuit Google willen ophalen? En zie mijn eerdere opmerking, met welke frequentie dan? Hoe rate je dit?
Als je ervaring hebt met mail services dan weet je toch ook dat dit een waardeloos idee is? Host dan je mailbox bij Google, maak een MX record en SPF etc aan en dan heb je behalve DNS niks te maken met Strato. Iedereen met ervaring op dit vlak heeft echt geen 2 minuten nodig om dit te bedenken.

[grasmanek94]

MasterL schreef op vrijdag 22 maart 2024 @ 13:38:
Erg kinderachtig om steeds je post te wijzigen n.a.v. opmerkingen om je gelijk te halen.

Ik haal niks weg, ik voeg verduidelijkingen toe, zodat het duidelijk wordt wat ik bedoel en mensen geen dingen gaan omdraaien.

Ik denk dat Strato gewoon de IP-adressen blokkeert waarvan veel request komen

Vermoed ik ook.

en terecht want dat is namelijk "abnormaal".

Niet mee eens.

Strato bied een simpele mail dienst aan (waarschijnlijk gekoppeld aan een domein) waarvan het idee is dat er misschien 10x per dag een request komt van een mail client op een pc'tje of mobieltje.

Waar haal je dat vandaan? Dat is nooit gecommuniceerd naar mij, en kan het niet vinden. Mijn conclusie is "onzin".

Weet jij hoevaak Google polled? 1x per uur, per minuut, per seconde, per milliseconde?

Ja Google geeft aan dat ze tussen de 1-3x per uur pollen, dat kan iedereen terug zien in de authenticatie logs.

Ga je Strato vragen c.q. verplichten om een uitzondering te maken voor Google omdat bepaalde klanten hun mail vanuit Google willen ophalen?

Dit is een normaal scenario, enige wat ik van ze wil is dat het werkt, hoe ze dat oplossen maakt mij niks uit, zolang ik (direct, of indirect via 3rd party providers) over TLS mijn mail veilig binnen kan halen, daar betaal ik voor.

En zie mijn eerdere opmerking, met welke frequentie dan? Hoe rate je dit?
Als je ervaring hebt met mail services dan weet je toch ook dat dit een waardeloos idee is? Host dan je mailbox bij Google, maak een MX record en SPF etc aan en dan heb je behalve DNS niks te maken met Strato. Iedereen met ervaring op dit vlak heeft echt geen 2 minuten nodig om dit te bedenken.

Waar ik mijn mail host discussie is dit niet het topic voor. Iedereen heeft zijn eigen overwegingen, ik heb zo mijn eigen, en die kunnen natuurlijk veranderen, maar nogmaals, dit is niet het topic daarvoor.

Als je alles bij 1 partij wilt hebben dan moet je dat zelf weten, maar in dit topic is dat zeker niet de oplossing voor iedereen aanwezig hier.

[ Voor 3% gewijzigd door grasmanek94 op 22-03-2024 14:00 ]

[joostgvr]

MasterL schreef op vrijdag 22 maart 2024 @ 13:38:
Als je ervaring hebt met mail services dan weet je toch ook dat dit een waardeloos idee is? Host dan je mailbox bij Google, maak een MX record en SPF etc aan en dan heb je behalve DNS niks te maken met Strato. Iedereen met ervaring op dit vlak heeft echt geen 2 minuten nodig om dit te bedenken.

Voor iedereen met wat minder ervaring en die toch graag meerdere mailboxen op 1 plek wil hebben blijft de pop3/imap toch de manier. Als het aanpassen van MX records de gangbare methode zou zijn, dan zou ik dat toch wel veel vaker ergens tegenkomen hoe dat werkt?
Ik wil graag leren over dit soort dingen, dus heb je ergens een resource hoe dit in te stellen zou zijn? ik weet nog net genoeg dat MX records bij je DNS records staan...

[grasmanek94]

joostgvr schreef op vrijdag 22 maart 2024 @ 13:44:
[...]
Als het aanpassen van MX records de gangbare methode zou zijn, dan zou ik dat toch wel veel vaker ergens tegenkomen hoe dat werkt?
Ik wil graag leren over dit soort dingen, dus heb je ergens een resource hoe dit in te stellen zou zijn? ik weet nog net genoeg dat MX records bij je DNS records staan...

Er zijn heel veel Tweakers die je daar graag bij helpen, maar die zullen niet dit topic openen om een dergelijke vraag te beantwoorden (die verwachten ze hier niet).
Ik raad je sterk aan om een nieuw topic hiervoor te openen, zo krijg je betere, meer en kwalitatievere antwoorden.

[ Voor 4% gewijzigd door grasmanek94 op 22-03-2024 13:57 ]

[MasterL]

grasmanek94 schreef op vrijdag 22 maart 2024 @ 13:43:
[...]


Ik haal niks weg, ik voeg verduidelijkingen toe, zodat het duidelijk wordt wat ik bedoel en mensen geen dingen gaan omdraaien.


[...]

Vermoed ik ook.

[...]

Niet mee eens.

[...]

Waar haal je dat vandaan? Dat is nooit gecommuniceerd naar mij, en kan het niet vinden. Mijn conclusie is "onzin".


[...]

Ja Google geeft aan dat ze tussen de 1-3x per uur pollen, dat kan iedereen terug zien in de authenticatie logs.


[...]

Dit is een normaal scenario, enige wat ik van ze wil is dat het werkt, hoe ze dat oplossen maakt mij niks uit, zolang ik (direct, of indirect via 3rd party providers) over TLS mijn mail veilig binnen kan halen, daar betaal ik voor.


[...]

Waar ik mijn mail host discussie is dit niet het topic voor. Iedereen heeft zijn eigen overwegingen, ik heb zo mijn eigen, en die kunnen natuurlijk veranderen, maar nogmaals, dit is niet het topic daarvoor.

Je hebt gelijk het is jouw keuze, ik probeer uit te leggen hoe en waarom Strato deze keuzes wellicht maakt em waarom ik als network/security engineer dezelfde keuzes zou maken. Ik probeer tevens een oplossing aan te dragen om deze problemen niet alleen nu maar ook in de toekomst te voorkomen maargoed succes met de helpdesk van Strato.

joostgvr schreef op vrijdag 22 maart 2024 @ 13:44:
[...]

Voor iedereen met wat minder ervaring en die toch graag meerdere mailboxen op 1 plek wil hebben blijft de pop3/imap toch de manier. Als het aanpassen van MX records de gangbare methode zou zijn, dan zou ik dat toch wel veel vaker ergens tegenkomen hoe dat werkt?
Ik wil graag leren over dit soort dingen, dus heb je ergens een resource hoe dit in te stellen zou zijn? ik weet nog net genoeg dat MX records bij je DNS records staan...

Ik zal het topic niet teveel kapen maar kijk bijvoorbeeld eens naar Microsoft 365 (als concept). Je hebt je mailboxes op 1 plek (365).
Een MX record geeft letterlijk aan op welke server je mail afgeleverd moet worden, dit kan dus overal zijn.
In mijn geval een server in mijn datacenter. Kan een server zijn op je zolder, Google,Microsoft jij bepaalt dit is de kracht van een eigen domein. Maargoed ik stop met dit topic want de conclusie is wel duidelijk en de oplossing eveneens. Of Strato laat zijn security een beetje varen (zou het niet doen) of je regelt je mail fatsoenlijk, als je advies wil over bovenstaande. Je kunt me altijd een PM sturen of een topic openen.

[grasmanek94]

MasterL schreef op vrijdag 22 maart 2024 @ 13:58:
n waarom Strato deze keuzes wellicht maakt em waarom ik als network/security engineer dezelfde keuzes zou maken. Ik probeer tevens een oplossing aan te dragen om deze problemen niet alleen nu maar ook in de toekomst te voorkomen maargoed succes met de helpdesk van Strato.

Je vergeet dan ook voor het gemak even alle mobiele providers met CGNAT, en alle mobieltjes in de wereld die een IMAP client gebruiken. Zelfde scenario, allemaal blokkeren dus en vereisen dat ze maar een uniek ip betalen ergens lijkt mij geen oplossing. De gebruiker zit dan in het scenario hoe jij het voor je ziet dat STRATO verkoopt:

Strato bied een simpele mail dienst aan (waarschijnlijk gekoppeld aan een domein) waarvan het idee is dat er misschien 10x per dag een request komt van een mail client op een pc'tje of mobieltje.

Die STRATO server die weet niet of het het mobieltje is, of de CGNAT router van de provider. Dus dan maar heel KPN, Odido, Vodafone enzv blokkeren? Als niemand erbij kan dan is het inderdaad veilig ja, of dat praktisch is? Ik betwijfel het.
En anders als die wel van een uitzonderingspositie genieten.. waarom wel Google LLC blokkeren maar niet KPN N.V.?

Dus STRATO gebruiken voor het scenario zoals jij het neer zet zal ook met dit probleem kampen (Op mijn mobieltje of pc'tje een IMAP client installeren en alleen die gebruiken). Heb je daar ook een oplossing voor?

En als je vanuit puur IPv6 perspectief wilt discussiëren, prima, hoe kan STRATO weten bij de hoeveelste bit het prive blok begint, en waar de provider mask eindigt? /48 ? /24? /32? /64?

Of een provider is zo respectloos dat ie IPv6NAT doet met een horror /128 scenario.
Of iemand zit op een IPv6 tunnel, of een IPv6-to-IPv4 tunnel..

Dat weten wij (de eindgebruikers) soms wel maar STRATO niet. Dus krijg je voor een bepaald blok ook die blokkade.

Zoals ik al zei, best kortzichtig, er zijn zoveel scenario's, aspecten, overwegingen, die wentel je niet af met "Ja gewoon alle /24 blokken die veel inloggen blokkeren, super veilig, want ik denk dat dat abnormaal is!".

[ Voor 31% gewijzigd door grasmanek94 op 22-03-2024 14:18 ]

[Duke of Savage]

grasmanek94 schreef op vrijdag 22 maart 2024 @ 13:11:
[...]

Dat het er niks meet te maken heeft is puur vanuit het definitief aspect. Prima als jij vanuit daar reageert, maar ga niet de realiteit negeren als het zijn wel dezelfde servers (of servers op hetzelfde netwerk blok) zijn. Ik weet niet zozeer wat je probeert te bereiken, dat is mij erg onduidelijk, en je gedrag komt gewoon troll-achtig over. Als je wilt laten zien hoeveel technische definities van e-mail en netwerking je bekend zijn, is dit niet het topic daarvoor. Verder ben je wel heel kortzichtig bezig, niet alles wordt puur gebruikt voor de technische definitie ervan, maar afijn.. en corrigeer even je "relatief onveilige" naar "gewoon veilig", want IMAP over TLS is gewoon veilig, dat is zo'n beetje uitgediscussieerd, tenzij je niet TLS gebruikt (Strato verplicht TLS). Dus geen onwaarheden spuwen. Of je leeft onder een steen, want poort 110 komt uit het dinosaurustijdperk, en ik betwijfel dat een service die respect heeft voor zichzelf en klanten, dit nog aanbied.

Ik ben bekend met e-mail security, authenticatie, verificatie, signing, enzv. Idem de netwerk en DNS kant wat dit issue betreft.
De servers die het ophalen hoeven niet dezelfde te zijn als servers die versturen - prima -, dat ze beide in die blokken vallen zal echt geen toeval zijn.


Makkelijkste wat STRATO kan doen is gewoon per-account security policies hebben, en het ip aspect weg laten vallen, maar dat is ook verre van de beste en veiligste oplossing. Een ding wat ik durf te zeggen naar aanleiding van anderen die dit mee maken, is dat het zeker niet mijn account is waarop gebruteforced is, integendeel, er is helemaal geen foute inlogpoging ondernomen voor mijn account vermoed ik.

Niet om het een en ander, maar een SPF record heeft niets te maken met e-mail ophalen.

Deze reactie van je geeft een Dunning Kruger effect gevoel. Je valt de gene best hard aan die je dat probeerd te vertellen.

Voordat je verder de boel in de fik steekt, heb je al antwoord van Strato?

[MasterL]

grasmanek94 schreef op vrijdag 22 maart 2024 @ 14:04:
[...]

Je vergeet dan ook voor het gemak even alle mobiele providers met CGNAT, en alle mobieltjes in de wereld die een IMAP client gebruiken. Zelfde scenario, allemaal blokkeren dus en vereisen dat ze maat een uniek ip betalen ergens lijkt mij geen oplossing. De gebruiker zit dan in het scenario hoe jij het voor je ziet dat STRATO verkoopt:

[...]


Die STRATO server die weet niet of het het mobieltje is, of de CGNAT router van de provider. Dus dan maar heel KPN, Odido, Vodafone enzv blokkeren? Als niemand erbij kan dan is het inderdaad veilig ja, of dat praktisch is? Ik betwijfel het.

Dit vergeet ik helemaal niet, ik hak letterlijk dagelijks met dit bijltje.
Het verschil is dat als iemand (lokaal) een mail client draait deze niet elke 1-3 uur zijn mail client opent en dan al zeker niet vanaf hetzelfde IP (wifi, andere netwerken enzo) en ja niet iedereeen op GGNAT gebruikt hetzelfde IP dus hier zit veel meer variatie in. Als meer mensen Google gebruiken met de 1-3 uur interval krijg je een exponentiële groei die moeilijk in te schatten en te voorspellen is. Dit triggert al heel snel IDS/IPS systemen. Wat ik niet snap is waarom mensen hun mail diensten niet centraliseren. Waarom mail ergens laten binnenkomen om het vervolgens te importeren ergens ander? Laat het afleveren op de server/dienst waar je daadwerkelijk gebruik van wil maken.

[grasmanek94]

Duke of Savage schreef op vrijdag 22 maart 2024 @ 14:19:
[...]


Niet om het een en ander, maar een SPF record heeft niets te maken met e-mail ophalen.

Ik weet waar SPF voor bedoelt is. In SPF van google staan super handige records voor uitgaande mail.
En ik kan je ook vertellen dat zeer waarschijnlijk is dat het geen toeval is dat de servers die de e-mail ophalen in dezelfde blokken vallen die de SPF records aangeven.

Het hoeven niet dezelfde servers te zijn, klopt. Er kunnen aparte servers zijn voor het sturen, en aparte voor het binnenhalen. Klopt helemaal. En hoe leg je anders uit dat de twee genoemde IP's in de SPF record voorkomen?
Google publiceert niet expliciet de IP adressen van de servers die mails ophalen. Dus dat is het enige aanknooppunt wat er is.

Verder is er een niet-veel-zeggend https://support.google.co...jid=254117008974131404-EU link, maar STRATO kan dus prima alle gepubliceerde adressen analyseren en verwerken in hun security. Maar deze is het enige artikel specifiek voor e-mail: https://support.google.co...jid=254117008974131404-EU

MasterL schreef op vrijdag 22 maart 2024 @ 14:21:
[...]
Waarom mail ergens laten binnenkomen om het vervolgens te importeren ergens ander? Laat het afleveren op de server/dienst waar je daadwerkelijk gebruik van wil maken.

Ja en hoe haalt iemand de mail dan op bij die dienst? Dan zal die iemand alsnog door een CGNAT of ander gedeeld blok moeten, dus komen we terug op hetzelfde probleem.
Be it een web interface of IMAP, alles bij een provider onderbrengen lost dit niet op. Die klant moet de mail alsnog ophalen via een apparaat, en als dat apparaat (be it in zijn direct beheer, of een indirect apparaat) via IDS/IPS/firewall systemen geblokkeerd is zijn we terug bij mijn oorspronkelijke post, maar dan niet dat Google niet werkt maar <mijn provider is geblokkeerd> of <via mijn 4g/5g werkt ophalen niet> etc. Alleen dan kan ik bij al mijn mail niet, in plaats van alleen de mails bij die ene provider. Dan maak ik wel een topic met de vraag of alle Odido klanten bij STRATO/andere dienst zijn geblokkeerd...

[ Voor 63% gewijzigd door grasmanek94 op 22-03-2024 14:40 ]

[Duke of Savage]

grasmanek94 schreef op vrijdag 22 maart 2024 @ 14:29:
[...]

Ik weet waar SPF voor bedoelt is. In SPF van google staan super handige records voor uitgaande mail.
En ik kan je ook vertellen dat zeer waarschijnlijk is dat het geen toeval is dat de servers die de e-mail ophalen in dezelfde blokken vallen die de SPF records aangeven.

Het hoeven niet dezelfde servers te zijn, klopt. Er kunnen aparte servers zijn voor het sturen, en aparte voor het binnenhalen. Klopt helemaal. En hoe leg je anders uit dat de twee genoemde IP's in de SPF record voorkomen?
Google publiceert niet expliciet de IP adressen van de servers die mails ophalen. Dus dat is het enige aanknooppunt wat er is.

Verder is er een niet-veel-zeggend https://support.google.co...jid=254117008974131404-EU link, maar STRATO kan dus prima alle gepubliceerde adressen analyseren en verwerken in hun security. Maar deze is het enige artikel specifiek voor e-mail: https://support.google.co...jid=254117008974131404-EU


[...]


Ja en hoe haalt iemand de mail dan op bij die dienst? Dan zal die iemand alsnog door een CGNAT of ander gedeeld blok moeten, dus komen we terug op hetzelfde probleem.
Be it een web interface of IMAP, alles bij een provider onderbrengen lost dit niet op. Die klant moet de mail alsnog ophalen via een apparaat, en als dat apparaat (be it in zijn direct beheer, of een indirect apparaat) via IDS/IPS/firewall systemen geblokkeerd is zijn we terug bij mijn oorspronkelijke post, maar dan niet dat Google niet werkt maar <mijn provider is geblokkeerd> of <via mijn 4g/5g werkt ophalen niet> etc. Alleen dan kan ik bij al mijn mail niet, in plaats van alleen de mails bij die ene provider. Dan maak ik wel een topic met de vraag of alle Odido klanten bij STRATO/andere dienst zijn geblokkeerd...

Je haalt 2 protocollen door elkaar. Je maakt aannames en bouwt erop alsof het feiten zijn.

Daarom stelde ik de vraag: Heb je al antwoord van Strato?

EDIT: Ter verduidelijking, je probleem zit in authenticatie, niet in het ophalen. Ophalen kan pas - na - authenticatie.

[MasterL]

grasmanek94 schreef op vrijdag 22 maart 2024 @ 14:29:
[...]

Ik weet waar SPF voor bedoelt is. In SPF van google staan super handige records voor uitgaande mail.
En ik kan je ook vertellen dat zeer waarschijnlijk is dat het geen toeval is dat de servers die de e-mail ophalen in dezelfde blokken vallen die de SPF records aangeven.

Het hoeven niet dezelfde servers te zijn, klopt. Er kunnen aparte servers zijn voor het sturen, en aparte voor het binnenhalen. Klopt helemaal. En hoe leg je anders uit dat de twee genoemde IP's in de SPF record voorkomen?
Google publiceert niet expliciet de IP adressen van de servers die mails ophalen. Dus dat is het enige aanknooppunt wat er is.

Verder is er een niet-veel-zeggend https://support.google.co...jid=254117008974131404-EU link, maar STRATO kan dus prima alle gepubliceerde adressen analyseren en verwerken in hun security. Maar deze is het enige artikel specifiek voor e-mail: https://support.google.co...jid=254117008974131404-EU


[...]


Ja en hoe haalt iemand de mail dan op bij die dienst? Dan zal die iemand alsnog door een CGNAT of ander gedeeld blok moeten, dus komen we terug op hetzelfde probleem.
Be it een web interface of IMAP, alles bij een provider onderbrengen lost dit niet op. Die klant moet de mail alsnog ophalen via een apparaat, en als dat apparaat (be it in zijn direct beheer, of een indirect apparaat) via IDS/IPS/firewall systemen geblokkeerd is zijn we terug bij mijn oorspronkelijke post, maar dan niet dat Google niet werkt maar <mijn provider is geblokkeerd> of <via mijn 4g/5g werkt ophalen niet> etc. Alleen dan kan ik bij al mijn mail niet, in plaats van alleen de mails bij die ene provider. Dan maak ik wel een topic met de vraag of alle Odido klanten bij STRATO/andere dienst zijn geblokkeerd...

Wat snap je niet aan exponentiële groei? Het gaat niet om 1 specifiek IP of account maar meerdere connecties vanaf een bepaald IP. Gaat een willekeurig GCNAT IP een poll doen elke 1-3 min? Nee tuurlijk niet want normaliter gebeurt dit alleen bij het openen van een mail client. Nu aan 100 mensen hun Google account laten pollen, elke 1-3 min een request...Reken het eens uit dit is simpele havo wiskunde

Duke of Savage schreef op vrijdag 22 maart 2024 @ 14:43:
[...]


Je haalt 2 protocollen door elkaar. Je maakt aannames en bouwt erop alsof het feiten zijn.

Daarom stelde ik de vraag: Heb je al antwoord van Strato?

EDIT: Ter verduidelijking, je probleem zit in authenticatie, niet in het ophalen. Ophalen kan pas - na - authenticatie.

Oneens, authenticatie is geen probleem aangezien dit "oke" is. het probleem imo is het teveel aan aan authenticatie request vanaf 1 source.

[ Voor 10% gewijzigd door MasterL op 22-03-2024 14:48 ]

[Duke of Savage]

MasterL schreef op vrijdag 22 maart 2024 @ 14:45:
[...]


Wat snap je niet aan exponentiële groei? Het gaat niet om 1 specifiek IP of account maar meerdere connecties vanaf een bepaald IP. Gaat een willekeurig GCNAT IP een poll doen elke 1-3 min? Nee tuurlijk niet want normaliter gebeurt dit alleen bij het openen van een mail client. Nu aan 100 mensen hun Google account laten pollen, elke 1-3 min een request...Reken het eens uit dit is simpele havo wiskunde


[...]


Oneens, authenticatie is geen probleem aangezien dit "oke" is. het probleem imo is het teveel aan aan authenticatie request vanaf 1 source.

Ah ja scherp van je, inderdaad. Vandaar de brute-force melding

[MasterL]

Duke of Savage schreef op vrijdag 22 maart 2024 @ 14:49:
[...]


Ah ja scherp van je, inderdaad. Vandaar de brute-force melding

Thanks maar daarom ook het advies om dit te vermijden.. Je hebt een mailbox, laat de mail daar afleveren en regel het centraal.

[ajaalbers]

Na een tijdje rust, krijg ik weer een bericht van Strato dat en een "aanval op je strato email account is geconstateerd".

Ook dit keer is het IP adres van Google .... dus weer de integratie met mijn gmail inbox die Strato onterecht als een aanval markeerd.

[basvn]

ajaalbers schreef op dinsdag 23 juli 2024 @ 08:45:
Na een tijdje rust, krijg ik weer een bericht van Strato dat en een "aanval op je strato email account is geconstateerd".

Ook dit keer is het IP adres van Google .... dus weer de integratie met mijn gmail inbox die Strato onterecht als een aanval markeerd.

Hier ook weer op 2 emailadressen ontvangen. (die in Gmail geïmporteerd worden)

[grasmanek94]

Yep, weer gaande..

[Fynx]

Helaas heb ik ze ook mogen ontvangen, had je verder nog iets van Strato gehoord?

[grasmanek94]

Fynx schreef op dinsdag 23 juli 2024 @ 16:40:
Helaas heb ik ze ook mogen ontvangen, had je verder nog iets van Strato gehoord?

Nee, heb geen contact meer met ze gehad. De 1e lijn support merk ik dat ik daar niet doorheen kom. Balen maarja.

Hopen maar dat iemand anders hier wel iemand aan de lijn krijgt die iets voor ons kan betekenen!

[Amsterdam2010]

Ik had ook weer hetzelfde (zowel in maart als vorige week). Sinds de mail van vorige week lukt het mij niet meer om het Strato account te configureren met gmail... Hebben meer mensen hier last van? Ik krijg steeds de melding "Geen POP3-toegang met de opgegeven gebruikersnaam en wachtwoord". Terwijl ik de juiste gebruikersnaam en wachtwoord invul. Of is gebruikersnaam niet hetzelfde als die bij Strato?

Tips voor ander programma dan Strato wat wel goed met Gmail werkt zijn ook welkom...

[ Voor 9% gewijzigd door Amsterdam2010 op 30-07-2024 11:14 . Reden: Nog een vraag toegevoegd ]

[valkenier]

Ik blijf me vebazen over mensen die Google hun mail laten ophalen bij een provider en het dan pas lezen. Google is niet privacy, dus niet doen
Het creëert een extra stap in de mailflow, dus vertraging.
Het geeft issues als hierboven

"Ja dan heb ik mijn mail op 1 plek". Iedere mailclient kan toch gewoon met meerdere accounts uit de voeten? Alsof dat alleen via Google kan.

Ik ben het volstrekt eens met @MasterL , dit is niet by design, en geeft dus issues. Anders inrichten dus, en google ertussen uit.