Mer enn 1000 norske bedrifter rammet av epostkaos etter at ISP ble sperret ute hos Google

[Martin Braathen Røise]

Mer enn 1000 norske bedrifter rammet av epostkaos etter at ISP ble sperret ute hos Google

[dabear]

Hva med å benytte VPN til det gamle datasenteret og sørge for at utgående epost går over VPN til det gamle datasenteret, og dermed får gammel IP?

 

Hvis det er sånn at de har bytta til nytt datasenter uten å ha begge datasentre tilgjengelig, så er det amatører som driver firmaet.

[-Night-]

Noen som har glemt og oppdatere SPF records virker det som. evt at TTL er satt veldig høy og de må først dø før google ber om nye. 

 

 

korrigerte skriveleif spf/sfp

Endret 5. januar 2017 av -Night-

[nomore]

Alternativt så snakker vi her om at de har tatt i bruk helt nye IP-adresser på utgående MTA-servere. Noen av de større e-posttilbyderene ser på nye IP-adresser som ikke har noen form for rykte(spam reputation) som risiko, og enten blokkerer eller setter på en forsinkelse(rate limiting). Vært borti det tidligere

[nomore]

Noen som har glemt og oppdatere SFP records virker det som. evt at TTL er satt veldig høy og de må først dø før google ber om nye. 

SPF. Men tvilsomt, da burde det ikke fungert mot Microsoft eller andre større leverandører.

[subsys as]

Noen som har glemt og oppdatere SFP records virker det som. evt at TTL er satt veldig høy og de må først dø før google ber om nye. 

 

Det var satt lav TTL i langt tid før flyttingen og det er ingen feil med SPF-recordene. Man har da holdt på en stund :-)

 

Dette er en (etter mitt syn) ganske urimelig trafikkbegrensning internt hos Google som slår inn.

 

Hilsen

Sturla Josdal

Subsys AS

[pitrh]

Det er helt normalt å tidvis krangle med Google om hva som er gyldig og rettmessig sendt epost. Dessverre er de ikke så veldig flinke til å svare med ord, men ofte går ting over etter noen timer.Min generelle erfaring er at Google er ganske strenge med å kreve at alle deler av alfabetsuppen som serveres via DNS (SPF, DKIM, DMARC) er korrekt satt opp og at alle involverte maskiner har korrekt reversoppslag (noe som det er skremmende vanlig å overse). I tillegg vil du komme ut for at de er om mulig enda strengere om du forsøker å levere til dem over IPv6. I tillegg må du gjerne lete litt for å finne frem til det faktum at de i praksis krever at du har enda en TXT-record i DNS for domenet du sender fra: Googles egen google-site-verification, som de genererer for deg om du finner frem til siden der du kan be om det.I slike tilfeller er det jo smart å ha rimelig utløpstid for alle elementer i DNS for domenet, noe nok alle som driver med epost og slikt profesjonelt egentlig vet godt.Noen av disse tingene er tatt med i https://bsdly.blogspot.no/2016/04/does-your-email-provider-know-what.html, men likevel skjer det tidvis at Google og dermed Gmail bestemmer seg for at noe automatisk utsendt fra meg selv til meg selv er spam og avviser, som i dette tilfellet:

While I wasn't looking, another round of #googlefail: my log summaries are *still* not spam, @google @gmail https://t.co/TNTbwGR3Qc— Peter N. M. Hansteen (@pitrh) December 28, 2016

Denne episoden gikk over etter noen få timer, men det aner meg at dette ikke vil være siste gang noe slikt skjer. Uansett, Google har fortsatt noe å streve mot for å bli mer tilnærmelige for begrunnede henvendelser om uheldige sider ved deres sannsynligvis høyst automatiserte system.

[Simen1]

Hva er det bitcoinminerne på illustrasjonsbildet skal illustrere med relevans til denne saken?

[pthorsheim]

Knallhard men også mangelfull/farlig SPF policy hos Subsys, og ingen DMARC. Blir ikke overrasket om det er ene og alene Subsys som er årsak til problemene. At Google er strengere på filtrering iht avsenders policy (Subsys) enn hva Microsoft er kan man liksom ikke klandre dem for....

[nomore]

Knallhard men også mangelfull/farlig SPF policy hos Subsys, og ingen DMARC. Blir ikke overrasket om det er ene og alene Subsys som er årsak til problemene. At Google er strengere på filtrering iht avsenders policy (Subsys) enn hva Microsoft er kan man liksom ikke klandre dem for....

Du tenker på at de bruker "-"(Fail) mekanismen i stede for "~"(SoftFail)?

[subsys as]

Knallhard men også mangelfull/farlig SPF policy hos Subsys, og ingen DMARC. Blir ikke overrasket om det er ene og alene Subsys som er årsak til problemene. At Google er strengere på filtrering iht avsenders policy (Subsys) enn hva Microsoft er kan man liksom ikke klandre dem for....

 

SPF-recorden er som den skal være. Det er ikke en mangel eller farlig at man har kontroll på hvilke servere man sender e-post via.

 

De fleste vil nok gjerne tro at Google gjør noe lurt og at det er minst 3 akronymer involvert, men det de gjør er å legge trafikkbegrensninger på nye ip-adresser. De blokkerer ikke alt slik de ville gjort hvis noe var feil, men de slipper gjennom ca 3-4 e-poster hvert 10. minutt.

 

Løsningen er å bare route e-posten til andre e-postservere (med "eldre" ip-adresser) så går alt gjennom.

[mmm...]

En responstid på 3-5 dager for operasjonelle henvendelser er ikke akkurat tillitvekkende.

[bmork]

SPF-recorden er som den skal være. Det er ikke en mangel eller farlig at man har kontroll på hvilke servere man sender e-post via.

Tja... Jeg noterer meg at SPF-record for subsys.no bare inneholder IPv4-adresser, til tross for at minst to av disse adressene tilsynelatende tilhørerer servere med dual stack (ns2.subsys.no og ns3.subsys.no har begge en AAAA record i tillegg). Det *kan* jo selvsagt være korrekt fordi f.eks. serverene er satt opp til å kun bruke IPv4 for utgående mail, men jeg tillater meg å tvile. Som kjent har Google vært tidlig ute med å bruke IPv6 for sine tjenester, og mail til googles mailservere vil derfor normalt bli levert via IPv6.

 

Også litt usikker på om det er lurt å bruke en SPF type RR i tillegg til TXT RR. Det burde ikke spille noen rolle ettersom de er identiske, men hvem vet. Jeg tror jeg ville droppet SPF-typen. Mulig Google ser den som et tegn på at noe ikke stemmer. Ref rfc7208 som sier tydelig "SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only."

 

Men alle diskusjoner om SPF. DMARC, DKIM osv for "subsys.no"-domenet er jo egentlig irrelevante. Det store ubesvarte spørsmålet er hvordan kundenes domener er konfigurert. De har neppe den samme stålkontrollen.

Endret 6. januar 2017 av bmork

[pitrh]

De fleste vil nok gjerne tro at Google gjør noe lurt og at det er minst 3 akronymer involvert, men det de gjør er å legge trafikkbegrensninger på nye ip-adresser. De blokkerer ikke alt slik de ville gjort hvis noe var feil, men de slipper gjennom ca 3-4 e-poster hvert 10. minutt.

 

Løsningen er å bare route e-posten til andre e-postservere (med "eldre" ip-adresser) så går alt gjennom.

 

Den varianten med trafikkbegrensninger på ikke tidligere sette IP-adresser er ny for meg, men det høres nesten ut som noen har prøvd å implementere noe som ligger veldig nær grålisting ("greylisting"). Ordentlig grålisting er jo en god ide og har vist seg å fungere godt i praksis. Jeg er litt mer skeptisk til det du beskriver, som høres ut som det har større porsjon tilfeldighet i seg enn grålisting.

[nomore]

Det er ikke noe nytt, og flere av de store gjør dette. Har selv opplevd at en ny e-postserver ble rate limited fordi adressen var ny og ikke hadde noe rykte.

[Kurt Lekanger]

Hva er det bitcoinminerne på illustrasjonsbildet skal illustrere med relevans til denne saken?

 

Oi - her har noen vært litt kjappe med å velge illustrasjonsbilde fra bildearkivet. Har byttet ut med et annet bilde nå. :-)