Genial, acum am ascultat, ar trebui sa fie tema lui Hackerman din Kung Fury 2.
On Wed, Apr 10, 2024 at 7:12 PM Dumitru Moldovan via RLUG <rlug@lists.lug.ro> wrote: > Mulțam pentru detalii! Se pare că ăsta îi viitorul, nimeni nu prea mai > înțelege ce face. Am cerut unui AI o creație muzicală pe tema > configurării SPF și mi-a produs ceva cam în aceeași notă: > https://suno.com/song/6f1f9b7d-beb7-4bb0-a690-e9a1872f37ec :-] > > (Să fie clar, sugestia mea a fost sub 10 cuvinte și neutră.) > > On 4/10/24 15:03, Mihai Badici via RLUG wrote: > > Bun, acum dacă chiar vrei răspunsul pe bune ăsta e mailul cel lung :) > > > > Evident că din punct de vedere tehnic nu aveam de ce să includ (o să zic > > mai jos și la ce m-am gândit) > > > > Problema e că eu am ajuns să intru pe scula Google (cred că prima dată, > > că nu o folosesc în general ) că eram ușor panicat/nedumerit: > > > > Dacă interogam 8.8.8.8 îmi rezolva spf-ul corect. Totuși mailurile erau > > rejectate cu spf fail. > > > > Pe scula google îmi arăta de asemenea spf-ul corect iar asta era singura > > "avertizare". > > > > Acum, concluzia e că totuși propagarea a durat mai mult decât mă > > așteptam eu. Nu a durat 24 de ore cât e în ttl dar câteva ore a durat. > > > > În plus probabil că rezolverele lor sunt mai multe și relativ > > independente, în așa fel încât am primit cel puțin două mesaje diferite > > corespunzătoare a două modificări pe care le făcusem între timp. Cumva > > eu având la DMARC policy "none" am interpretat unul din mesaje în sensul > > că ar trebui să am o politică mai strictă și am schimbat în reject.... > > > > Surprinzător, mesajul s-a schimbat corespunzător, în sensul că nu îmi > > mai zicea că nu am SPF ci că am DMARC cu reject. (parcă am dat ambele > > mesaje pe listă ieri) > > > > Acum, la rece, probabil că situația probabil e așa sau așa mi-o explic > eu: > > > > Probabil că în funcție de serverul gmail care răspunde, resolverul poate > > să aibă sau să nu aibă înregistrarea în cache, iar dacă nu o are poate > > face o interogare și să obțină chiar înregistrarea curentă. > > > > Dacă a doua oară răspunde un alt server, care are înregistrarea în cache > > de acum să zicem 2 ore, o poate avea pe cea veche și cum ttl-ul nu e > > expirat o consideră validă. > > > > Și mai complicat, dacă filtrarea se face pe altă mașină decât cea de > > smtp, care la rândul ei are și ea resolverul ei, poți să ai trei > > înregistrări diferite pe trei mașini dacă o modifici de mai multe ori. > > > > Până la urmă soluția a fost să nu fac nimic și să aștept, pe seară > > mesajele au început să fie livrate. Dar evident între timp tot primeam > > reclamații de la client, că sunt destul de mulți useri :) > > > > > > Acum, la ce m-am gândit eu și motivul pentru care mă apucase amocul: > > > > Dacă tu îți redirectezi mesajele cu un filtru simplu, cum cred că se mai > > face și acum la cpanel, există situația în care să zicem, eu îți scriu > > ție de la mi...@badici.ro la adresa ta, dar adresa ta e forwardată spre > > gmail; așa gmail o să primească un mesaj de la mine cu originea în > > serverul tău, care va da SPF fail. E situația care a fost și cu lista > > asta acum câteva luni și nu are o soluție prea simplă fără să rescrii > > headerele. > > > > Ce m-am gândit eu în nemernicia mea: să vezi că cei de la gmail, ca să > > nu se mai complice, vor să ne forțeze să îi punem și pe ei în spf ca să > > nu aibă probleme. Da, știu că nu e cusher, dar în general nu mi se pare > > că google sau outlook sunt în general cusher.... > > > > > > > > On 4/10/24 14:34, Dumitru Moldovan via RLUG wrote: > >> On 4/9/24 17:26, Mihai Badici via RLUG wrote: > >>> > >>> Hai să punem problema altfel: ai un domeniu altundeva decât la gmail? > >>> care nu include spf,google.com ? Dacă poți trimite la gmail înseamnă > >>> că sunt eu paranoic și trebuie doar să aștept și am închis theradul. > >> > >> Dacă nu folosești Google Workspace pentru a primi mail pentru un > >> anumit domeniu, de ce ai include _spf.google.com în înregistrarea SPF > >> pentru acel domeniu? Doar pentru că așa spune scula Google făcută > >> pentru cei ce folosesc Google Workspace pentru mail? > >> > >> Întreb, nu dau cu parul… Și io am inclus din motive destul de obscure > >> spf.protection.outlook.com și calendar-server.bounces.google.com în > >> înregistrarea SPF pentru un domeniu ce primește mail în Google > >> Workspace. Dar mi-aduc aminte că rapoartele DMARC relevau niște > >> subtilități la cate nu te-ai fi așteptat, de exemplu în privința > >> invitațiilor pe mail la meeting generate automat din Google Calendar. > >> > >> Apropo de DMARC… Rapoartele îs zilnice, per destinație, că se întreba > >> cineva. Unde prin „destinație” putem presupune în cam 60% din cazuri > >> Google, vreo 20% Microsoft și restul până în 20% Yahoo, Zoho și altele > >> și mai exotice. Personal, nu-s prea încântat de situația asta în care > >> mai bine de 80% din mail-uri se duc la doar două companii, dar măcar > >> îs mai puțin rapoarte DMARC zilnice. Ce-i drept, nici nu te mai uiți > >> pe ele după ce au dispărut problemele inițiale… > >> > >> _______________________________________________ > >> RLUG mailing list > >> RLUG@lists.lug.ro > >> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > > > > _______________________________________________ > > RLUG mailing list > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > > > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
