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
