Re: [rlug] gmail requirement

2024-04-11 Fir de Conversatie Mihai Badici via RLUG 
De lămurit m-am lămurit după primele două mailuri, după aia discuția a 
evoluat într-o direcție care nu mai avea nici o noimă pentru că evident 
dacă pleci de la alte ipoteze ajungi de cele mai multe ori la alte 
concluzii.


Înclusiv la analiza pe domeniul meu deși eu precizasem încâ de pe la 
început că nu de el e vorba. Ca și data trecută cu containerele.


Dacă ar fi fost o problemă de la gmail probabil că ar fi fost suficiente 
confirmări în primele 10 minute. Așa... cumva înțeleg și de ce s-a stins 
traficul pe lista asta, care eu zic că ar mai fi avut încă o noimă de 
"semi-socializare cu beneficii IT", dar na, se zice că IT-știi sunt 
oricum antisociali deci nu trebuie :)


On 4/12/24 08:46, Petru Rațiu wrote:


Practic având după ip4: mx  parserul lor încearcă să interpreteze
tot ce vine după, chiar dacă urmează spațiu, ca pe un ip. În cazul
de față am mx și îmi dă eroarea de mai sus. Mailul s-a livrat
totuși pentru că aici am măcar DKIM, dincolo nu am semnătură deci
dădea reject direct.
SPF-ul e acum
  v=spf1 ip4:86.121.235.42 ip4:86.121.235.40/29
 ip4:82.77.138.91 ip4: mx
~all ( corectez mai pe seară). Și cu asta cred că am elucidat tot
ce era
de elucidat, fiecare e liber să creadă ce vrea. Îmi cer scuze și lui
Petre, încă consider că atitudinea lui inițială a fost mai agresivă
decât simplul trolling obișnuit pe listă- dar pot supraviețui cu
asta,
nu sunt milenial ca să mă simt ofensat de orice mărunțiș și oricum nu
mi-am trimis CV-ul pe nicăieri ca să mă încurce părerea negativă a
unuia
sau altuia. Cu un pic de respect eu cred că treaba se lămurea mai
repede
(dealtfel s-a "lămurit de la sine" c ă eu tot postez de trei zile iar
sistemul funcționează din aceeași seară) A bon entandeur salut Mihai


Atitudinea e proportionala cu pretentiile. Ce voiam sa zic e ca cu un 
extra dram de "hai ca poate nu google e de vina, sa ma mai uit o data 
in curtea mea" te prindeai mai repede, am compensat fix in directia 
aia. Bine ca te-ai lamurit pana la urma.


--
P.

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-11 Fir de Conversatie Petru Rațiu via RLUG 
> Practic având după ip4: mx  parserul lor încearcă să interpreteze tot ce
> vine după, chiar dacă urmează spațiu, ca pe un ip. În cazul de față am mx
> și îmi dă eroarea de mai sus. Mailul s-a livrat totuși pentru că aici am
> măcar DKIM, dincolo nu am semnătură deci dădea reject direct.
> SPF-ul e acum
>   v=spf1 ip4:86.121.235.42 ip4:86.121.235.40/29 ip4:82.77.138.91 ip4: mx
> ~all ( corectez mai pe seară). Și cu asta cred că am elucidat tot ce era
> de elucidat, fiecare e liber să creadă ce vrea. Îmi cer scuze și lui
> Petre, încă consider că atitudinea lui inițială a fost mai agresivă
> decât simplul trolling obișnuit pe listă- dar pot supraviețui cu asta,
> nu sunt milenial ca să mă simt ofensat de orice mărunțiș și oricum nu
> mi-am trimis CV-ul pe nicăieri ca să mă încurce părerea negativă a unuia
> sau altuia. Cu un pic de respect eu cred că treaba se lămurea mai repede
> (dealtfel s-a "lămurit de la sine" c ă eu tot postez de trei zile iar
> sistemul funcționează din aceeași seară) A bon entandeur salut Mihai
>
>
Atitudinea e proportionala cu pretentiile. Ce voiam sa zic e ca cu un extra
dram de "hai ca poate nu google e de vina, sa ma mai uit o data in curtea
mea" te prindeai mai repede, am compensat fix in directia aia. Bine ca
te-ai lamurit pana la urma.

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-11 Fir de Conversatie Mihai Badici via RLUG 
hai că urmănd îndemnul tuturor am mai citit odată încercând să trag 
măcar niște concluzii și am încercat să reproduc problema folosind un 
alt domeniu care e al meu și deci pot să îl spun.


"E drept că există o asemenea problemă în realitate, dar chiar nu te 
ajută să adaugi chestii SPF de la Google într-o înregistrare proprie SPF 
într-un asemenea caz pentru că serverele Google îs la primire în cazul 
descris, nu trimit nimic. "


Păi asta e valabil în cazul în care filtrul spf ar funcționa corect. 
Pentru că eu eram convins că înregistrarea spf era corectă (nu era 
pentru că nu se propagase cea corectă) concluzia logică a fost că 
filtrul lor spf nu funcționează corect și m-am concentrat pe ce ar putea 
să nu fie ok. (sigur, acum e clar că ipoteza mea a fost greșită dar 
atunci eram în situația în care eram în ceață). Tot din același motiv am 
încercat să pun ip-ul deși aveam deja toată subclasa la ip4, în ideea că 
poate e o problemă de parser. Evident dacă era o problemă în spf-ul de 
la gmail ar fi sesizat-o și altcineva, de aici ideea de a scrie pe 
listă. Când din link-ul lor de troubleshoot ajungi la o aplicație care 
îți spune că e MUST să incluzi SPF-ul google... fandaxia-i gata. Acum 
trebuie să îmi cer scuze și la domnul google că i-am bănuit că au scris 
un parser greșit (sau răuvoitor). Câtă vreme n-aș fi fost convins că 
inregistrarea SPF era corectă nu mă apucam să postez...



Ce am obținut acum:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=passheader.i=@machinet.ro  header.s=default header.b=czKtumhB;
   dkim=passheader.i=@machinet.ro  header.s=default header.b=czKtumhB;
   spf=permerror (google.com: domain ofmihai.bad...@machinet.ro  Error 
parsing SPF record: illegal mechanism: 
ip4:mx)smtp.mailfrom=mihai.bad...@machinet.ro;
   dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=machinet.ro


Practic având după ip4: mx  parserul lor încearcă să interpreteze tot ce vine 
după, chiar dacă urmează spațiu, ca pe un ip. În cazul de față am mx și îmi dă 
eroarea de mai sus. Mailul s-a livrat totuși pentru că aici am măcar DKIM, 
dincolo nu am semnătură deci dădea reject direct.
SPF-ul e acum
 v=spf1 ip4:86.121.235.42 ip4:86.121.235.40/29 ip4:82.77.138.91 ip4: mx 
~all ( corectez mai pe seară). Și cu asta cred că am elucidat tot ce era 
de elucidat, fiecare e liber să creadă ce vrea. Îmi cer scuze și lui 
Petre, încă consider că atitudinea lui inițială a fost mai agresivă 
decât simplul trolling obișnuit pe listă- dar pot supraviețui cu asta, 
nu sunt milenial ca să mă simt ofensat de orice mărunțiș și oricum nu 
mi-am trimis CV-ul pe nicăieri ca să mă încurce părerea negativă a unuia 
sau altuia. Cu un pic de respect eu cred că treaba se lămurea mai repede 
(dealtfel s-a "lămurit de la sine" c ă eu tot postez de trei zile iar 
sistemul funcționează din aceeași seară) A bon entandeur salut Mihai



On 4/11/24 10:42, Mihai Badici via RLUG wrote:


Domeniul meu are spf-ul de la gmail pentru că am avut mailul la ei cât 
era gratis și nu am catadicit să îl scot. De fapt e acelasi spf de 
foarte multă vreme pentru că am mai folosit serverul actual pentru 
trimis diverse rapoarte (în principal nagios) și înainte. Deci 
ip-urile erau deja în SPF. Nu era cazul respectivului client.
Situația menționată cu redirectarea este reală, dacă zici că primești 
rapoarte dmarc o să vezi că se mai întâmplă încă, e drept cu setup-uri 
mai vechi.
Ceea ce era ciudat alaltăieri era că doar gmail îmi rejecta mailurile; 
cred că respectivul client are mai mulți clienți la yahoo și totuși 
yahoo nu rejecta. Nici serverul meu nu rejecta, deși are și el spf 
policy activ. Din cauza asta mi s-a părut ciudat. Încă o dată, rostul 
mesajului pe listă a fost să confirm că e doar o problemă a mea. Daca 
eu dau un mesaj pe listă să întreb dacă voi puteți accesa whatsapp 
răspunsul poate fi da, pot sau nu, nu pot. E problemă de la mine sau 
de la ei. Restul e doar trolling. Dacă mă întrebi daca știu să 
instalez whatsapp...

"tool-ul care e facut sa te ajute sa configurezi un domeniu pentru a-l

muta pe google workspace."
Acel tool nu e prezentat ca tool de migrare și am ajuns la el din 
sectiunea de troubleshooting. Deci părea ca e "requirement" ( și în 
plus imi afișa SPF-ul valid, după corectare). Evident că asta ar fi 
fost un abuz, de unde și tonul postării inițiale (care avea și un jpeg 
atașat însă...)
Cred că am dat destule explicații pentru cei care vor să priceapă. 
Pentru  troli, feel free.




On 2024-04-11 10:09, Dumitru Moldovan via RLUG wrote:

On 4/10/24 22:20, George-Cristian Bîrzan via RLUG wrote:

On Wed, 10 Apr 2024 at 20:24, Mihai Badici via RLUG 
wrote:


Eu înțeleg foarte bine cum funcționează SPF



Atat de bine incat ai adaugat _spf.google.com la al tau, pentru ca 
asa ti-a
zis tool-ul care e facut sa te ajute sa configurezi un domeniu 
pentru a-l

muta pe google workspace.


+1.  Pe mine m-a bufnit râsul când am citit cuvintele citate. În 
fine, dacă e să mai învățăm ceva din g

Re: [rlug] gmail requirement

2024-04-11 Fir de Conversatie Mihai Badici via RLUG 


Domeniul meu are spf-ul de la gmail pentru că am avut mailul la ei cât 
era gratis și nu am catadicit să îl scot. De fapt e acelasi spf de 
foarte multă vreme pentru că am mai folosit serverul actual pentru 
trimis diverse rapoarte (în principal nagios) și înainte. Deci ip-urile 
erau deja în SPF. Nu era cazul respectivului client.
Situația menționată cu redirectarea este reală, dacă zici că primești 
rapoarte dmarc o să vezi că se mai întâmplă încă, e drept cu setup-uri 
mai vechi.
Ceea ce era ciudat alaltăieri era că doar gmail îmi rejecta mailurile; 
cred că respectivul client are mai mulți clienți la yahoo și totuși 
yahoo nu rejecta. Nici serverul meu nu rejecta, deși are și el spf 
policy activ. Din cauza asta mi s-a părut ciudat. Încă o dată, rostul 
mesajului pe listă a fost să confirm că e doar o problemă a mea. Daca eu 
dau un mesaj pe listă să întreb dacă voi puteți accesa whatsapp 
răspunsul poate fi da, pot sau nu, nu pot. E problemă de la mine sau de 
la ei. Restul e doar trolling. Dacă mă întrebi daca știu să instalez 
whatsapp...

"tool-ul care e facut sa te ajute sa configurezi un domeniu pentru a-l

muta pe google workspace."
Acel tool nu e prezentat ca tool de migrare și am ajuns la el din 
sectiunea de troubleshooting. Deci părea ca e "requirement" ( și în plus 
imi afișa SPF-ul valid, după corectare). Evident că asta ar fi fost un 
abuz, de unde și tonul postării inițiale (care avea și un jpeg atașat 
însă...)
Cred că am dat destule explicații pentru cei care vor să priceapă. 
Pentru  troli, feel free.




On 2024-04-11 10:09, Dumitru Moldovan via RLUG wrote:

On 4/10/24 22:20, George-Cristian Bîrzan via RLUG wrote:
On Wed, 10 Apr 2024 at 20:24, Mihai Badici via RLUG 


wrote:


Eu înțeleg foarte bine cum funcționează SPF



Atat de bine incat ai adaugat _spf.google.com la al tau, pentru ca asa 
ti-a
zis tool-ul care e facut sa te ajute sa configurezi un domeniu pentru 
a-l

muta pe google workspace.


+1.  Pe mine m-a bufnit râsul când am citit cuvintele citate.  În fine, 
dacă e să mai învățăm ceva din greșelile aproapelui nostru, cred că mai 
îi cel puțin o deficiență majoră de înțelegere a mecanismelor SPF în 
cele două paragrafe citate mai jos:


«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»


E drept că există o asemenea problemă în realitate, dar chiar nu te 
ajută să adaugi chestii SPF de la Google într-o înregistrare proprie 
SPF într-un asemenea caz pentru că serverele Google îs la primire în 
cazul descris, nu trimit nimic.  Eu mă gândeam că Mihai are vreun 
client cu aliasuri Gmail configurate pe stilul vechi, când nu puteai 
preciza serverul SMTP per alias, caz de care m-am lovit în practică, 
dar nu mai țin minte să fi avut nevoie de asemenea hăcuieli prin 
înregistrări SPF.


Cu toate astea, vreau să precizez că eu nu înțeleg „foarte bine” multe 
chestii pe care le am în administrare.  Deci ironia cu piesa AI pe tema 
SPF era și auto-ironică… La modul general, cu cât aflu mai multe, cu 
atât realizez cât de puține lucruri înțeleg de fapt. Generalizarea 
depășește domeniul nostru strâmt de activitate.



___
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

Re: [rlug] gmail requirement

2024-04-11 Fir de Conversatie Dumitru Moldovan via RLUG 

On 4/10/24 22:20, George-Cristian Bîrzan via RLUG wrote:

On Wed, 10 Apr 2024 at 20:24, Mihai Badici via RLUG 
wrote:


Eu înțeleg foarte bine cum funcționează SPF



Atat de bine incat ai adaugat _spf.google.com la al tau, pentru ca asa ti-a
zis tool-ul care e facut sa te ajute sa configurezi un domeniu pentru a-l
muta pe google workspace.


+1.  Pe mine m-a bufnit râsul când am citit cuvintele citate.  În fine, 
dacă e să mai învățăm ceva din greșelile aproapelui nostru, cred că mai 
îi cel puțin o deficiență majoră de înțelegere a mecanismelor SPF în 
cele două paragrafe citate mai jos:


«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»


E drept că există o asemenea problemă în realitate, dar chiar nu te 
ajută să adaugi chestii SPF de la Google într-o înregistrare proprie SPF 
într-un asemenea caz pentru că serverele Google îs la primire în cazul 
descris, nu trimit nimic.  Eu mă gândeam că Mihai are vreun client cu 
aliasuri Gmail configurate pe stilul vechi, când nu puteai preciza 
serverul SMTP per alias, caz de care m-am lovit în practică, dar nu mai 
țin minte să fi avut nevoie de asemenea hăcuieli prin înregistrări SPF.


Cu toate astea, vreau să precizez că eu nu înțeleg „foarte bine” multe 
chestii pe care le am în administrare.  Deci ironia cu piesa AI pe tema 
SPF era și auto-ironică… La modul general, cu cât aflu mai multe, cu 
atât realizez cât de puține lucruri înțeleg de fapt. Generalizarea 
depășește domeniul nostru strâmt de activitate.



___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie George-Cristian Bîrzan via RLUG 
On Wed, 10 Apr 2024 at 20:24, Mihai Badici via RLUG 
wrote:

> Eu înțeleg foarte bine cum funcționează SPF
>


Atat de bine incat ai adaugat _spf.google.com la al tau, pentru ca asa ti-a
zis tool-ul care e facut sa te ajute sa configurezi un domeniu pentru a-l
muta pe google workspace.


-- 
George-Cristian Bîrzan
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Petru Rațiu via RLUG 
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 
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 rapo

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Mircea Ciocan via RLUG 
Now kiss and cut it down ;)

Mircea "eNough iz iNough" C.

On Wed, Apr 10, 2024 at 8:47 PM Mihai Badici via RLUG 
wrote:

> Mai mult nu știu ce pot face pentru tine. Trebuie să te gândești și tu
> că tot făcându-i pe alții incompetenți s-ar putea să ți se întoarcă
> tratamentul.
>
> Ceea ce am avut nevoie atunci era o confirmare sau o infirmare a unei
> situații. Nu s-a putut, n-a fost cu supărare, m-am descurcat ulterior...
>
> Am expus logica după care am analizat situația, am recunoscut unde am
> greșit...  De mult nu am mai avut nevoie de suport la configurare de pe
> lista lug, sunt lucruri cu care lucrez des și le cunosc bine, altele cu
> care lucrez rar și le știu mai puțin bine, ca toată lumea.
>
> Pentru configurări e plin netul de tutoriale, s-a mai discutat topicul
> ăsta. Când apare o situație care îi poate afecta pe mai mulți e util un
> mesaj pe listă exact din motivul ăsta. Dacă ești singurul care are
> problema... e de la tine. Am priceput și am remediat.
>
> Sănătate!
>
>
> On 4/10/24 21:36, Petru Rațiu via RLUG wrote:
> > On Wed, Apr 10, 2024 at 8:25 PM Mihai Badici via RLUG  >
> > wrote:
> >
> >> Eu înțeleg foarte bine cum funcționează SPF dar aici la DNS ai dreptate
> >> că am făcut o presupunere greșită și anume că dacă DNS-ul public al
> >> google a updatat recordul și respectivele servere o să rezolve la fel,
> >> plecând de la ideea că au o arhitectură mai centralizată ceea ce s-a
> >> dovedit că nu e adevărat.
> >>
> >> Cumva am observat o anomalie și am avut o reacție care s-a dovedit
> >> greșită dar ideea de a analiza cauza anomaliei era corectă. Intre timp
> >> mi-am răspuns singur când am avut posibilitatea să testez de la un
> >> domeniu care îndeplinea condițiile.
> >>
> >> Nu poți să mergi pe ideea că tot ce face gmail e bine; probabil că în
> >> 90% din cazuri e, poate și în 99%, dar uneori se mai întâmplă. De aici
> >> ironia cu Titanicul ; de ți-am greșit, îmi cer iertare...
> >>
> >> As zice ca e 99.9% sa fi gresit TU ceva, nu gmail, in special cand nu
> stii
> > ce se intampla. Au si ei bubele lor in cap, dar trebuie higher standard
> of
> > proof decat "eu am incercat si m-am incurcat".
> >
> > Also, alea nu sunt niste scuze acceptabile pe masura insultei, dar am
> facut
> > prea multi km azi ca sa mai fac circ. Sper sa-mi amintesc la threadurile
> > viitoare sa dau cu drop.
> >
>
> ___
> 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

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Mihai Badici via RLUG 
Mai mult nu știu ce pot face pentru tine. Trebuie să te gândești și tu 
că tot făcându-i pe alții incompetenți s-ar putea să ți se întoarcă 
tratamentul.


Ceea ce am avut nevoie atunci era o confirmare sau o infirmare a unei 
situații. Nu s-a putut, n-a fost cu supărare, m-am descurcat ulterior...


Am expus logica după care am analizat situația, am recunoscut unde am 
greșit...  De mult nu am mai avut nevoie de suport la configurare de pe 
lista lug, sunt lucruri cu care lucrez des și le cunosc bine, altele cu 
care lucrez rar și le știu mai puțin bine, ca toată lumea.


Pentru configurări e plin netul de tutoriale, s-a mai discutat topicul 
ăsta. Când apare o situație care îi poate afecta pe mai mulți e util un 
mesaj pe listă exact din motivul ăsta. Dacă ești singurul care are 
problema... e de la tine. Am priceput și am remediat.


Sănătate!


On 4/10/24 21:36, Petru Rațiu via RLUG wrote:

On Wed, Apr 10, 2024 at 8:25 PM Mihai Badici via RLUG 
wrote:


Eu înțeleg foarte bine cum funcționează SPF dar aici la DNS ai dreptate
că am făcut o presupunere greșită și anume că dacă DNS-ul public al
google a updatat recordul și respectivele servere o să rezolve la fel,
plecând de la ideea că au o arhitectură mai centralizată ceea ce s-a
dovedit că nu e adevărat.

Cumva am observat o anomalie și am avut o reacție care s-a dovedit
greșită dar ideea de a analiza cauza anomaliei era corectă. Intre timp
mi-am răspuns singur când am avut posibilitatea să testez de la un
domeniu care îndeplinea condițiile.

Nu poți să mergi pe ideea că tot ce face gmail e bine; probabil că în
90% din cazuri e, poate și în 99%, dar uneori se mai întâmplă. De aici
ironia cu Titanicul ; de ți-am greșit, îmi cer iertare...

As zice ca e 99.9% sa fi gresit TU ceva, nu gmail, in special cand nu stii

ce se intampla. Au si ei bubele lor in cap, dar trebuie higher standard of
proof decat "eu am incercat si m-am incurcat".

Also, alea nu sunt niste scuze acceptabile pe masura insultei, dar am facut
prea multi km azi ca sa mai fac circ. Sper sa-mi amintesc la threadurile
viitoare sa dau cu drop.



___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Petru Rațiu via RLUG 
On Wed, Apr 10, 2024 at 8:25 PM Mihai Badici via RLUG 
wrote:

> Eu înțeleg foarte bine cum funcționează SPF dar aici la DNS ai dreptate
> că am făcut o presupunere greșită și anume că dacă DNS-ul public al
> google a updatat recordul și respectivele servere o să rezolve la fel,
> plecând de la ideea că au o arhitectură mai centralizată ceea ce s-a
> dovedit că nu e adevărat.
>
> Cumva am observat o anomalie și am avut o reacție care s-a dovedit
> greșită dar ideea de a analiza cauza anomaliei era corectă. Intre timp
> mi-am răspuns singur când am avut posibilitatea să testez de la un
> domeniu care îndeplinea condițiile.
>
> Nu poți să mergi pe ideea că tot ce face gmail e bine; probabil că în
> 90% din cazuri e, poate și în 99%, dar uneori se mai întâmplă. De aici
> ironia cu Titanicul ; de ți-am greșit, îmi cer iertare...
>
> As zice ca e 99.9% sa fi gresit TU ceva, nu gmail, in special cand nu stii
ce se intampla. Au si ei bubele lor in cap, dar trebuie higher standard of
proof decat "eu am incercat si m-am incurcat".

Also, alea nu sunt niste scuze acceptabile pe masura insultei, dar am facut
prea multi km azi ca sa mai fac circ. Sper sa-mi amintesc la threadurile
viitoare sa dau cu drop.

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Mihai Badici via RLUG 
Btw, ieri în timp ce făceam teste am primit trei rapoarte DMARC de la 
google pe respectivul domeniu deși în general sunt zilnice, așa cum zici.


Posibil ca schimbarea de zonă să declanșeze un trigger,  asta chiar nu știu.

Sincer nu prea văd mare utilitate pentru tool-ul ăsta (DMARC)  ( SPF-ul 
chiar e util iar DKIM e destul de delicat că odată semnat nu mai poți 
prelucra mailul) ; câtă vreme poți să folosești policy none nu prea văd 
mare folos. De aia chiar mi-a trecut prin minte că or fi făcut 
enforcement la policy-ul din DMARC, pentru că dacă îl dai cu reject sau 
softfail chiar înseamnă ceva.


E drept că toate astea au marele avantaj implicit că fac diferența între 
un server care are un administrator și unul care nu are deloc. Am 
întâlnit și un RBL, nu mai știu care era, care părea că funcționează pe 
principiul ăsta. "ești blocat, delistează-te". Fără nici o explicație 
iar delistarea funcționa fără nici o verificare. Până la urmă e foarte 
eficient, pentru că presupune să existe un client care reclamă și un 
admin care face delistarea, ceea ce deja e aproape sigur un business 
legitim :)




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

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Mihai Badici via RLUG 
Eu înțeleg foarte bine cum funcționează SPF dar aici la DNS ai dreptate 
că am făcut o presupunere greșită și anume că dacă DNS-ul public al 
google a updatat recordul și respectivele servere o să rezolve la fel, 
plecând de la ideea că au o arhitectură mai centralizată ceea ce s-a 
dovedit că nu e adevărat.


Cumva am observat o anomalie și am avut o reacție care s-a dovedit 
greșită dar ideea de a analiza cauza anomaliei era corectă. Intre timp 
mi-am răspuns singur când am avut posibilitatea să testez de la un 
domeniu care îndeplinea condițiile.


Nu poți să mergi pe ideea că tot ce face gmail e bine; probabil că în 
90% din cazuri e, poate și în 99%, dar uneori se mai întâmplă. De aici 
ironia cu Titanicul ; de ți-am greșit, îmi cer iertare...




On 4/10/24 20:08, Petru Rațiu via RLUG wrote:

Acum, dacă vine Petre


Mă străduiam să tac politicos din gură dar ai decis tu să dai în fabrici și
uzine.

Explicația mai simplă pe care mi-o șoptește tov. Ockham în cască e că tu nu
prea înțelegi cum funcționează DNS în general și miniprotocoalele astea gen
SPF în particular și în loc să îți admiți lacunele și eventual să le și
acoperi o dai în teoriile conspirației și un pic de sindromul persecuției.

Acum care-ți scuze pt aia cu oamenii care ar fi murit teoretic pe
responsabilitatea mea, că mă jigneai mai puțin dacă te luai de mama.



___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Petru Rațiu via RLUG 
> Acum, dacă vine Petre


Mă străduiam să tac politicos din gură dar ai decis tu să dai în fabrici și
uzine.

Explicația mai simplă pe care mi-o șoptește tov. Ockham în cască e că tu nu
prea înțelegi cum funcționează DNS în general și miniprotocoalele astea gen
SPF în particular și în loc să îți admiți lacunele și eventual să le și
acoperi o dai în teoriile conspirației și un pic de sindromul persecuției.

Acum care-ți scuze pt aia cu oamenii care ar fi murit teoretic pe
responsabilitatea mea, că mă jigneai mai puțin dacă te luai de mama.

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Mihai Badici via RLUG 
Nu știu dacă ai observat dar Gmail e la fel de puțin transparent ca și 
Microsoft


Acum, dacă vine Petre (care cred că ar fi fost bun de căpitan pe 
Titanic, ar fi murit toți dar n-ar fi fost nici o panică pentru că e 
maestru la "e normal, nu te agita"  :) ) probabil că explicatia ar fi așa:


În general rezolverul public al google e folosit de clienți de web și 
related; cum clientul meu are un site de firmă pe care nu intră nimeni 
în mod special e foarte posibil ca înregistrarea să nu fi fost în cache, 
așa că atunci când o interogam evident îmi dădea versiunea curentă că 
interoga direct DNS-ul meu.


În schimb ce or avea ei pentru serverele de mail e folosit pentru mail, 
mailurile către gmail sunt mult mai frecvente, deci probabilitatea ca 
înregistrarea să fie în cache e mare, deci e foarte probabil să îți 
răspundă din cache, ergo cu înregistrarea de ieri.


Dar asta e o logică la rece și post factum, la acel moment nu am avut o 
explicație rațională așa că am mers către conspirație :)


 Mai e și amănuntul că practic un parser mai de treabă nu ar fi 
considerat neapărat înregistrarea invalidă, ci ar fi putut foarte bine 
să ignore respectivul record. Dar uneori când intrii la o idee, 
fandaxia-i gata. Mă așteptam ca după atâta buzz cu AI-ul utilitarul lor 
măcar să vadă că MX-ul tău nu e la gmail și să-i și pese, nu să dea 
mesaje cu "MUST" ...


În fine, ideea e că dacă într-o bună zi gmail chiar o să ceară asta nu 
știu dacă o să fie mulți care să se opună... Până la urmă e serverul 
lor, primesc de la cine vor. Și așa la majoritatea nu ai absolut nici un 
control asupra felului în care marchează mesajele ca "spam" așa că tot 
ei fac jocurile anyway...



On 4/10/24 19:11, Dumitru Moldovan via RLUG 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 :)


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

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Dumitru Moldovan via RLUG 
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
RL

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Mihai Badici via RLUG 

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

Re: [rlug] gmail requirement

2024-04-10 Fir de Conversatie Dumitru Moldovan via RLUG 

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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 
Da, gata, s-a propagat, merci Petre că m-ai îndemnat să am răbdare, mă 
panicasem oțârișică :)


Altfel aveam de toate (minus DKIM că e Exchange), că doar tot eu l-am 
făcut și pe al meu și pe ăsta.



On 4/9/24 17:10, Petru Rațiu via RLUG wrote:

On Tue, Apr 9, 2024 at 5:04 PM Cristian Paslaru  wrote:


Corect, dar daca trimiti normal ca pe vremuri prin sendmai -t sau ceva de
genul, se prinde ca nu este authenticated, si nu il accepta.

Vroiam doar sa mentionez ca nu mai este de ajuns SPF pentru gmail, asa a
inceput thread-ul ;)





___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 
Ceea ce mă derutează e că serverul lor public, ăla cu 8.8.8.8, a 
înregistrat deja modificarea, dar probabil că nu au o politică uniformă.


Schimbările - au fost doar una care s-a lăsat cu eroarea de sintaxă, am 
vrut să adaug noul ip de transport în SPF și probabil am vrut de două 
ori pentru că era o dată cu ip4: valoare , corect, și încă o dată ip4:


Dar dacă zici că se ia după ttl, chiar dacă am incrementat serialul, 
totul capătă o logică, pentru că asta se petrecea ieri iar problema a 
fost raportată azi, după 24 de ore.


La partea asta cu DNS nu prea am avut ocazia să sap așa că aici pot să 
îmi recunosc deschis incompetența...


On 4/9/24 17:42, Petru Rațiu wrote:
As zice ca esti paranoic dar domeniul cu care am eu treaba day-to-day 
se intampla sa aiba mailboxurile la gmail si ca atare ma descalific, 
las pe altii sa-ti zica. :)


Dar valorile alea pe care le-ai dat acolo sunt cele din SOA care afaik 
afecteaza mai mult transferul de zona si alte scheme cu replicarea (mi 
se par putin exagerate numerele dar aia e alta discutie). Ce conteaza 
e TTL-ul de pe recordul ala de spf (care e fie explicit pus pe el in 
bind, fie mai probabil directiva de $TTL din zona). Cel mai simplu 
afli cat e dand dig in serverul autoritar, dar dpdv propagare conteaza 
cat era valoarea veche in caz ca ai schimbat-o (ie. daca aveai ttl de 
2 saptamani si o schimbi la 5 minute, tot 2 saptamani astepti sa stii 
ca noul record s-a propagat).


Dand un pas inapoi, se pare ca gmailul se plange ca n-a mers nici spf 
nici dkim si ar fi vrut macar una. SPF se refera la ip-ul de pe care a 
primit, dkim la cheia cu care s-a semnat. Acum tu stii ce a fost 
inainte si ce schimbari ai facut da' daca le-ai schimbat recent pe 
toate, e de inteles de ce e problematic. Vezi ca poti avea si dmarc 
policy publicat in dns unde sa-ti dea aggregate reports cu ce nu i-a 
placut (dar recunosc ca n-am folosit niciodata mecanismul ala si 
probabil implica si mai multa rabdare anyway, cred ca e daily report).


Te-as fi intrebat domeniul sa ma uit in diverse scule de dns ce si cum 
s-a propagat, dar cred ca am facut destul community work pe ziua de 
azi, pot sa-mi petrec restul zilei cu chestii mai productive.


--
P.

On Tue, Apr 9, 2024 at 5:26 PM Mihai Badici  wrote:

Nu îmi e rușine să dau domeniul pe listă dar e un domeniu al unui
client, nu vreau să îl implic.


Asta am în bind:

200    ; refresh (3 minutes 20 seconds)
7200   ; retry (2 hours)
120    ; expire (2 minutes)
240    ; minimum (4 minutes)

Nici de voodoo nu e vorba ci de faptul că gmail are mai multe
servere și probabil nu toate interoghează același DNS și/sau
eventual fiecare are cache-ul lui.

SPF-ul e :

v=spf1 include:_spf.google.com 
ip4:777.120.69.42/32 mx ip4:777.120.69.40/27 ip4:777.2.148.84/32
  ip4:777.2.145.246/32  ~all

(am pus și google.com  ca să văd dacă e vreo
schimbare, Am schimbat prima grupă cu 777 ca să fie totuși un pic
anonimizat.)

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.


On 4/9/24 17:16, Petru Rațiu wrote:




Am făcut o eroare de sintaxă (ieri) în SPF, în sensul că am
lăsat un ip4:  ( fără IP completat) îsă am corectat-o de cel
puțin două ore. Știu că oficial DNS-ul se propagă în timp mai
mult dar în practică probabil că sunt 10 ani de când nu mi
s-a mai întâmplat să facă mai mult de 10 ore.

Mai aștept.

Hai ca nici aici nu e vreun mare mister. "propagarea" dns-ului nu
inseamna in cat timp se misca, ci in cat timp se invalideaza
cache-urile cu recordul vechi. I.e. in general dureaza "up to"
ttl-ul de la recordul care era inainte. Vad ca la badici.ro
 ai (acum) 1h, dar banuiesc ca la domeniul cu
pricina era ceva mai mult. Mai sunt niste stelute cu posibile
cache-uri care nu tin cont de ttl, dar n-am mai vazut de-alea de
mult.

Sorry de spam dar ma triggereaza speculatii de-astea de "naiba
stie ce voodoo fac aia acolo" in special de la oameni care ar
trebui sa stie mai bine.

Also, daca ti-e rusine sa dai numele domeniului pe lista, hai pe
irc si discutam acolo (cu amendamentul ca iti iei si mistocareala
proportional :) ).

-- 
P.



___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
As zice ca esti paranoic dar domeniul cu care am eu treaba day-to-day se
intampla sa aiba mailboxurile la gmail si ca atare ma descalific, las pe
altii sa-ti zica. :)

Dar valorile alea pe care le-ai dat acolo sunt cele din SOA care afaik
afecteaza mai mult transferul de zona si alte scheme cu replicarea (mi se
par putin exagerate numerele dar aia e alta discutie). Ce conteaza e TTL-ul
de pe recordul ala de spf (care e fie explicit pus pe el in bind, fie mai
probabil directiva de $TTL din zona). Cel mai simplu afli cat e dand dig in
serverul autoritar, dar dpdv propagare conteaza cat era valoarea veche in
caz ca ai schimbat-o (ie. daca aveai ttl de 2 saptamani si o schimbi la 5
minute, tot 2 saptamani astepti sa stii ca noul record s-a propagat).

Dand un pas inapoi, se pare ca gmailul se plange ca n-a mers nici spf nici
dkim si ar fi vrut macar una. SPF se refera la ip-ul de pe care a primit,
dkim la cheia cu care s-a semnat. Acum tu stii ce a fost inainte si ce
schimbari ai facut da' daca le-ai schimbat recent pe toate, e de inteles de
ce e problematic. Vezi ca poti avea si dmarc policy publicat in dns unde
sa-ti dea aggregate reports cu ce nu i-a placut (dar recunosc ca n-am
folosit niciodata mecanismul ala si probabil implica si mai multa rabdare
anyway, cred ca e daily report).

Te-as fi intrebat domeniul sa ma uit in diverse scule de dns ce si cum s-a
propagat, dar cred ca am facut destul community work pe ziua de azi, pot
sa-mi petrec restul zilei cu chestii mai productive.

-- 
P.

On Tue, Apr 9, 2024 at 5:26 PM Mihai Badici  wrote:

> Nu îmi e rușine să dau domeniul pe listă dar e un domeniu al unui client,
> nu vreau să îl implic.
>
>
> Asta am în bind:
>
>   200; refresh (3 minutes 20 seconds)
>7200   ; retry (2 hours)
>120; expire (2 minutes)
>240; minimum (4 minutes)
>
> Nici de voodoo nu e vorba ci de faptul că gmail are mai multe servere și
> probabil nu toate interoghează același DNS și/sau eventual fiecare are
> cache-ul lui.
>
> SPF-ul e :
>
> v=spf1 include:_spf.google.com ip4:777.120.69.42/32 mx
> ip4:777.120.69.40/27 ip4:777.2.148.84/32   ip4:777.2.145.246/32  ~all
>
> (am pus și google.com ca să văd dacă e vreo schimbare, Am schimbat prima
> grupă cu 777 ca să fie totuși un pic anonimizat.)
>
> 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.
>
>
> On 4/9/24 17:16, Petru Rațiu wrote:
>
>
>
>
> Am făcut o eroare de sintaxă (ieri) în SPF, în sensul că am lăsat un ip4:
>> ( fără IP completat) îsă am corectat-o de cel puțin două ore. Știu că
>> oficial DNS-ul se propagă în timp mai mult dar în practică probabil că sunt
>> 10 ani de când nu mi s-a mai întâmplat să facă mai mult de 10 ore.
>>
>> Mai aștept.
>>
> Hai ca nici aici nu e vreun mare mister. "propagarea" dns-ului nu inseamna
> in cat timp se misca, ci in cat timp se invalideaza cache-urile cu recordul
> vechi. I.e. in general dureaza "up to" ttl-ul de la recordul care era
> inainte. Vad ca la badici.ro ai (acum) 1h, dar banuiesc ca la domeniul cu
> pricina era ceva mai mult. Mai sunt niste stelute cu posibile cache-uri
> care nu tin cont de ttl, dar n-am mai vazut de-alea de mult.
>
> Sorry de spam dar ma triggereaza speculatii de-astea de "naiba stie ce
> voodoo fac aia acolo" in special de la oameni care ar trebui sa stie mai
> bine.
>
> Also, daca ti-e rusine sa dai numele domeniului pe lista, hai pe irc si
> discutam acolo (cu amendamentul ca iti iei si mistocareala proportional :)
> ).
>
> --
> P.
>
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 
Nu îmi e rușine să dau domeniul pe listă dar e un domeniu al unui 
client, nu vreau să îl implic.



Asta am în bind:

200    ; refresh (3 minutes 20 seconds)
7200   ; retry (2 hours)
120    ; expire (2 minutes)
240    ; minimum (4 minutes)

Nici de voodoo nu e vorba ci de faptul că gmail are mai multe servere și 
probabil nu toate interoghează același DNS și/sau eventual fiecare are 
cache-ul lui.


SPF-ul e :

v=spf1 include:_spf.google.com ip4:777.120.69.42/32 mx 
ip4:777.120.69.40/27 ip4:777.2.148.84/32   ip4:777.2.145.246/32  ~all


(am pus și google.com ca să văd dacă e vreo schimbare, Am schimbat prima 
grupă cu 777 ca să fie totuși un pic anonimizat.)


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.



On 4/9/24 17:16, Petru Rațiu wrote:




Am făcut o eroare de sintaxă (ieri) în SPF, în sensul că am lăsat
un ip4: ( fără IP completat) îsă am corectat-o de cel puțin două
ore. Știu că oficial DNS-ul se propagă în timp mai mult dar în
practică probabil că sunt 10 ani de când nu mi s-a mai întâmplat
să facă mai mult de 10 ore.

Mai aștept.

Hai ca nici aici nu e vreun mare mister. "propagarea" dns-ului nu 
inseamna in cat timp se misca, ci in cat timp se invalideaza 
cache-urile cu recordul vechi. I.e. in general dureaza "up to" ttl-ul 
de la recordul care era inainte. Vad ca la badici.ro 
 ai (acum) 1h, dar banuiesc ca la domeniul cu 
pricina era ceva mai mult. Mai sunt niste stelute cu posibile 
cache-uri care nu tin cont de ttl, dar n-am mai vazut de-alea de mult.


Sorry de spam dar ma triggereaza speculatii de-astea de "naiba stie ce 
voodoo fac aia acolo" in special de la oameni care ar trebui sa stie 
mai bine.


Also, daca ti-e rusine sa dai numele domeniului pe lista, hai pe irc 
si discutam acolo (cu amendamentul ca iti iei si mistocareala 
proportional :) ).


--
P.

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
Am făcut o eroare de sintaxă (ieri) în SPF, în sensul că am lăsat un ip4:
> ( fără IP completat) îsă am corectat-o de cel puțin două ore. Știu că
> oficial DNS-ul se propagă în timp mai mult dar în practică probabil că sunt
> 10 ani de când nu mi s-a mai întâmplat să facă mai mult de 10 ore.
>
> Mai aștept.
>
Hai ca nici aici nu e vreun mare mister. "propagarea" dns-ului nu inseamna
in cat timp se misca, ci in cat timp se invalideaza cache-urile cu recordul
vechi. I.e. in general dureaza "up to" ttl-ul de la recordul care era
inainte. Vad ca la badici.ro ai (acum) 1h, dar banuiesc ca la domeniul cu
pricina era ceva mai mult. Mai sunt niste stelute cu posibile cache-uri
care nu tin cont de ttl, dar n-am mai vazut de-alea de mult.

Sorry de spam dar ma triggereaza speculatii de-astea de "naiba stie ce
voodoo fac aia acolo" in special de la oameni care ar trebui sa stie mai
bine.

Also, daca ti-e rusine sa dai numele domeniului pe lista, hai pe irc si
discutam acolo (cu amendamentul ca iti iei si mistocareala proportional :)
).

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
On Tue, Apr 9, 2024 at 5:04 PM Cristian Paslaru  wrote:

> Corect, dar daca trimiti normal ca pe vremuri prin sendmai -t sau ceva de
> genul, se prinde ca nu este authenticated, si nu il accepta.
>
> Vroiam doar sa mentionez ca nu mai este de ajuns SPF pentru gmail, asa a
> inceput thread-ul ;)
>
>
>
Citez bucata relevanta din headerele din mailul ala:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass header.i=@badici.ro header.s=dkim header.b=gXMEtzLi;
   dkim=pass header.i=@badici.ro header.s=dkim header.b=gXMEtzLi;
   spf=pass (google.com: domain of mi...@badici.ro designates
86.121.235.42 as permitted sender) smtp.mailfrom=mi...@badici.ro;
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=badici.ro
Return-Path: 
Received: from mail.machinet.ro (mail.machinet.ro. [86.121.235.42])
by mx.google.com with ESMTPS id
d19-20020a05600c34d300b004166b86088fsi2720466wmq.134.2024.04.09.05.41.54
for 
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 09 Apr 2024 05:41:54 -0700 (PDT)
Received-SPF: pass (google.com: domain of mi...@badici.ro designates
86.121.235.42 as permitted sender) client-ip=86.121.235.42;
Authentication-Results: mx.google.com;
   dkim=pass header.i=@badici.ro header.s=dkim header.b=gXMEtzLi;
   dkim=pass header.i=@badici.ro header.s=dkim header.b=gXMEtzLi;
   spf=pass (google.com: domain of mi...@badici.ro designates
86.121.235.42 as permitted sender) smtp.mailfrom=mi...@badici.ro;
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=badici.ro
Received: from localhost (localhost [127.0.0.1]) by mail.machinet.ro
(Postfix) with ESMTP id 2FE2B3B2004B; Tue,
  9 Apr 2024 15:41:53 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=badici.ro;
s=dkim; t=1712666513; bh=laxP/m9pM8pyi+5sb+/sxbjyYkD06WkvV7bjUjhZlAs=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=gXMEtzLiiF/5qQ2A3GEUQA/ZWqVRuxd1x/7MdFZFJC6jtj/VxfanrQ6s/bYpQ0JcD
 T+WN/F3rGeAtFm0CO1H7aL9Cdq5T2XlP6XMz1sTmCnaOxvTH0PGGmV9BuJhVwSNMQ4
 etY1XoDysfNREgCbLTiCWlDJmGuBTCtjCjfYpmxI27eBgL/lTAzxqGqNjM4Bg+LmCm
 H8nm2SIOlMgGLJixvqIYuASl9Tg50YHfuupK0uZAcLw56n6XHd7G/tqnHiHnmoNMzP
 89e2tMGKJdyvCQTGWagXUGAxE5Y6DWnrYZEqO1fgY4Y+/s0sDarp1TrOmqBZU+E2xV
 xFRCntmGnmKXw==
X-Virus-Scanned: Debian amavisd-new at mail.machinet.ro

Pare sa aiba de toate, nu inteleg problema. Si daca nu de badici.ro
discutam, de ce era asta in linkul la care se minuna in primul mail?  :)


(ok, a raspuns in alt mail in timp ce scriam aici, dau oricum send)

Ca sa nu raspund si la ala: Mihai, verifica ce ttl au recordurile alea cu
spf si dkim si verifica dupa ce a trecut timpul ala dupa schimbare. Pana
atunci, 200 de "tatal nostru" si invatat sa faci intai schimbarile in dns
si sa astepti sa se propage :)

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 

E plin de miștocari de la o vreme :)


On 4/9/24 17:00, Dumitru Moldovan via RLUG wrote:

On 4/9/24 16:56, Petru Rațiu via RLUG wrote:
On Tue, Apr 9, 2024 at 4:48 PM Cristian Paslaru  
wrote:




https://blog.google/products/gmail/gmail-security-authentication-spam-protection/ 





*By February 2024, Gmail will start to require that bulk
senders:Authenticate their email: You shouldn’t need to worry about the
intricacies of email security standards, but you should be able to
confidently rely on an email’s source. So we're requiring those who 
send

significant volumes to strongly authenticate their emails following
well-established best practices. Ultimately, this will close loopholes
exploited by attackers that threaten everyone who uses email.*


Astea le zic la fiecare schimbare, ma indoiesc ca badici.ro e bulk 
sender,

si vad ca Mihai e oricum vag confuz despre ce e spf-ul si cu ce ne ajuta
sau incurca el in viata. Asteptam logurile si o descriere mai adecvata a
problemei inainte sa speculam. Cum ziceam si mai devreme, mailul 
catre mine
a fost livrat direct si n-a mieunat absolut nimic prin headere, 
suspectez o

problema de layer 8 undeva.



Gata, am încurcat-o…  Iar urmează zeci de mesaje, din ce în ce mai 
lungi, ca să ne lămurească că știa el ce face, dar nu s-a exprimat 
îndeajuns de bine ca să-l înțelegem noi de la început.


Pușca și cureaua lată, ce admini eram odată! :D


___
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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 

Nu e vorba de domeniul badici.ro

Există o oarecare șansă să nu fi așteptat suficient de mult propagarea 
DNS-ului pentru că am alternativ fie


*Unauthenticated email from xxx .ro not accepted due to domain's DMARC 
policy*


*fie*

*Gmail requires all senders to authenticate with either SPF or DKIM. 
Authentication results: DKIM = did not pass SPF= did not pass*


Cum cred că e cam târziu să discutăm despre noutate când vorbim de SPF 
am încercat să verific ce spune gmail.com iar gmail, indiferent ce 
domeniu verifici spune asta, am scris pe listă în ideea ca cineva să îmi 
confirme ceea ce zice Petre, că help-ul e doar pentru utilizatorii lor.


Am făcut o eroare de sintaxă (ieri) în SPF, în sensul că am lăsat un 
ip4:  ( fără IP completat) îsă am corectat-o de cel puțin două ore. Știu 
că oficial DNS-ul se propagă în timp mai mult dar în practică probabil 
că sunt 10 ani de când nu mi s-a mai întâmplat să facă mai mult de 10 ore.


Mai aștept.



On 4/9/24 16:56, Petru Rațiu via RLUG wrote:

On Tue, Apr 9, 2024 at 4:48 PM Cristian Paslaru  wrote:


https://blog.google/products/gmail/gmail-security-authentication-spam-protection/



*By February 2024, Gmail will start to require that bulk
senders:Authenticate their email: You shouldn’t need to worry about the
intricacies of email security standards, but you should be able to
confidently rely on an email’s source. So we're requiring those who send
significant volumes to strongly authenticate their emails following
well-established best practices. Ultimately, this will close loopholes
exploited by attackers that threaten everyone who uses email.*



Astea le zic la fiecare schimbare, ma indoiesc ca badici.ro e bulk sender,
si vad ca Mihai e oricum vag confuz despre ce e spf-ul si cu ce ne ajuta
sau incurca el in viata. Asteptam logurile si o descriere mai adecvata a
problemei inainte sa speculam. Cum ziceam si mai devreme, mailul catre mine
a fost livrat direct si n-a mieunat absolut nimic prin headere, suspectez o
problema de layer 8 undeva.


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Cristian Paslaru via RLUG 
Corect, dar daca trimiti normal ca pe vremuri prin sendmai -t sau ceva de
genul, se prinde ca nu este authenticated, si nu il accepta.

Vroiam doar sa mentionez ca nu mai este de ajuns SPF pentru gmail, asa a
inceput thread-ul ;)



On Tue, Apr 9, 2024 at 3:57 PM Petru Rațiu  wrote:

>
>
> On Tue, Apr 9, 2024 at 4:48 PM Cristian Paslaru 
> wrote:
>
>>
>> https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
>>
>>
>>
>> *By February 2024, Gmail will start to require that bulk
>> senders:Authenticate their email: You shouldn’t need to worry about the
>> intricacies of email security standards, but you should be able to
>> confidently rely on an email’s source. So we're requiring those who send
>> significant volumes to strongly authenticate their emails following
>> well-established best practices. Ultimately, this will close loopholes
>> exploited by attackers that threaten everyone who uses email.*
>>
>>
> Astea le zic la fiecare schimbare, ma indoiesc ca badici.ro e bulk
> sender, si vad ca Mihai e oricum vag confuz despre ce e spf-ul si cu ce ne
> ajuta sau incurca el in viata. Asteptam logurile si o descriere mai
> adecvata a problemei inainte sa speculam. Cum ziceam si mai devreme, mailul
> catre mine a fost livrat direct si n-a mieunat absolut nimic prin headere,
> suspectez o problema de layer 8 undeva.
>
> --
> P.
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Dumitru Moldovan via RLUG 

On 4/9/24 16:56, Petru Rațiu via RLUG wrote:

On Tue, Apr 9, 2024 at 4:48 PM Cristian Paslaru  wrote:



https://blog.google/products/gmail/gmail-security-authentication-spam-protection/



*By February 2024, Gmail will start to require that bulk
senders:Authenticate their email: You shouldn’t need to worry about the
intricacies of email security standards, but you should be able to
confidently rely on an email’s source. So we're requiring those who send
significant volumes to strongly authenticate their emails following
well-established best practices. Ultimately, this will close loopholes
exploited by attackers that threaten everyone who uses email.*



Astea le zic la fiecare schimbare, ma indoiesc ca badici.ro e bulk sender,
si vad ca Mihai e oricum vag confuz despre ce e spf-ul si cu ce ne ajuta
sau incurca el in viata. Asteptam logurile si o descriere mai adecvata a
problemei inainte sa speculam. Cum ziceam si mai devreme, mailul catre mine
a fost livrat direct si n-a mieunat absolut nimic prin headere, suspectez o
problema de layer 8 undeva.



Gata, am încurcat-o…  Iar urmează zeci de mesaje, din ce în ce mai 
lungi, ca să ne lămurească că știa el ce face, dar nu s-a exprimat 
îndeajuns de bine ca să-l înțelegem noi de la început.


Pușca și cureaua lată, ce admini eram odată! :D


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
On Tue, Apr 9, 2024 at 4:48 PM Cristian Paslaru  wrote:

>
> https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
>
>
>
> *By February 2024, Gmail will start to require that bulk
> senders:Authenticate their email: You shouldn’t need to worry about the
> intricacies of email security standards, but you should be able to
> confidently rely on an email’s source. So we're requiring those who send
> significant volumes to strongly authenticate their emails following
> well-established best practices. Ultimately, this will close loopholes
> exploited by attackers that threaten everyone who uses email.*
>
>
Astea le zic la fiecare schimbare, ma indoiesc ca badici.ro e bulk sender,
si vad ca Mihai e oricum vag confuz despre ce e spf-ul si cu ce ne ajuta
sau incurca el in viata. Asteptam logurile si o descriere mai adecvata a
problemei inainte sa speculam. Cum ziceam si mai devreme, mailul catre mine
a fost livrat direct si n-a mieunat absolut nimic prin headere, suspectez o
problema de layer 8 undeva.

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Cristian Paslaru via RLUG 
https://blog.google/products/gmail/gmail-security-authentication-spam-protection/



*By February 2024, Gmail will start to require that bulk
senders:Authenticate their email: You shouldn’t need to worry about the
intricacies of email security standards, but you should be able to
confidently rely on an email’s source. So we're requiring those who send
significant volumes to strongly authenticate their emails following
well-established best practices. Ultimately, this will close loopholes
exploited by attackers that threaten everyone who uses email.*

https://support.google.com/a/answer/81126?hl=en


On Tue, Apr 9, 2024 at 3:21 PM Petru Rațiu via RLUG 
wrote:

> Funnily enough, mailul la care am dat eu reply a fost livrat de serverul
> ala catre gmail si... a mers? Deci, mai exact, ce nu merge?
>
> --
> P.
>
> On Tue, Apr 9, 2024 at 4:19 PM Petru Rațiu  wrote:
>
> > Probabil ar fi mai util sa zici ce eroare da si de unde trimiti mailul.
> > Dpdv SPF, vad ca ai softfail si le-ar accepta doar daca vin de la /29-le
> > ala, de la ip-ul mx-ului sau de la ip-ul lui badici.ro (care se
> suprapun,
> > dar na). Esti sigur ca mailul ala dat nu si-a luat un snat pe drum? Sau
> s-a
> > dus pe ipv6? Sau poate alta cauza nelegata de spf care ar putea fi
> > mentionata in mesajul de reject...
> >
> > --
> > P.
> >
> > On Tue, Apr 9, 2024 at 3:41 PM Mihai Badici  wrote:
> >
> >> Problema e că îmi rejectează mailurile de la un domeniu valid cu SPF
> >> valid...
> >>
> >> Încă nu sunt sigur 100% că asta  e problema dar momentan nu găsesc o
> altă
> >> explicație, iar wizardul nu îmi dă nici o altă avertizare.
> >>
> >> Din întâmplare eu chiar am avut mailurile la gmail și de lene nu am mai
> >> scos directiva cu _include gmail, dar nu e cazul celorlalți.
> >>
> >>
> >> On 2024-04-09 15:36, Petru Rațiu wrote:
> >>
> >> Poate pentru că toolul ăla e gândit să ajute adminii de domenii care AU
> >> mailul hostat la gmail...
> >>
> >> On Tue, 9 Apr 2024, 15:33 Mihai Badici via RLUG, 
> >> wrote:
> >>
> >> On 2024-04-09 15:11, Mihai Badici via RLUG wrote:
> >> > WTF? SPF must allow google servers to send mails on your behalf?
> >> >
> >> > Mailul nu e, evident, hostat la gmail...
> >> Scuze, asta e listă de acum 20 de ani și nu permite atșamente:   :)
> >>
> >>
> https://toolbox.googleapps.com/apps/checkmx/check?domain=badici.ro&dkim_selector=
> >>
> >> ___
> >> 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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
Funnily enough, mailul la care am dat eu reply a fost livrat de serverul
ala catre gmail si... a mers? Deci, mai exact, ce nu merge?

-- 
P.

On Tue, Apr 9, 2024 at 4:19 PM Petru Rațiu  wrote:

> Probabil ar fi mai util sa zici ce eroare da si de unde trimiti mailul.
> Dpdv SPF, vad ca ai softfail si le-ar accepta doar daca vin de la /29-le
> ala, de la ip-ul mx-ului sau de la ip-ul lui badici.ro (care se suprapun,
> dar na). Esti sigur ca mailul ala dat nu si-a luat un snat pe drum? Sau s-a
> dus pe ipv6? Sau poate alta cauza nelegata de spf care ar putea fi
> mentionata in mesajul de reject...
>
> --
> P.
>
> On Tue, Apr 9, 2024 at 3:41 PM Mihai Badici  wrote:
>
>> Problema e că îmi rejectează mailurile de la un domeniu valid cu SPF
>> valid...
>>
>> Încă nu sunt sigur 100% că asta  e problema dar momentan nu găsesc o altă
>> explicație, iar wizardul nu îmi dă nici o altă avertizare.
>>
>> Din întâmplare eu chiar am avut mailurile la gmail și de lene nu am mai
>> scos directiva cu _include gmail, dar nu e cazul celorlalți.
>>
>>
>> On 2024-04-09 15:36, Petru Rațiu wrote:
>>
>> Poate pentru că toolul ăla e gândit să ajute adminii de domenii care AU
>> mailul hostat la gmail...
>>
>> On Tue, 9 Apr 2024, 15:33 Mihai Badici via RLUG, 
>> wrote:
>>
>> On 2024-04-09 15:11, Mihai Badici via RLUG wrote:
>> > WTF? SPF must allow google servers to send mails on your behalf?
>> >
>> > Mailul nu e, evident, hostat la gmail...
>> Scuze, asta e listă de acum 20 de ani și nu permite atșamente:   :)
>>
>> https://toolbox.googleapps.com/apps/checkmx/check?domain=badici.ro&dkim_selector=
>>
>> ___
>> 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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
Probabil ar fi mai util sa zici ce eroare da si de unde trimiti mailul.
Dpdv SPF, vad ca ai softfail si le-ar accepta doar daca vin de la /29-le
ala, de la ip-ul mx-ului sau de la ip-ul lui badici.ro (care se suprapun,
dar na). Esti sigur ca mailul ala dat nu si-a luat un snat pe drum? Sau s-a
dus pe ipv6? Sau poate alta cauza nelegata de spf care ar putea fi
mentionata in mesajul de reject...

-- 
P.

On Tue, Apr 9, 2024 at 3:41 PM Mihai Badici  wrote:

> Problema e că îmi rejectează mailurile de la un domeniu valid cu SPF
> valid...
>
> Încă nu sunt sigur 100% că asta  e problema dar momentan nu găsesc o altă
> explicație, iar wizardul nu îmi dă nici o altă avertizare.
>
> Din întâmplare eu chiar am avut mailurile la gmail și de lene nu am mai
> scos directiva cu _include gmail, dar nu e cazul celorlalți.
>
>
> On 2024-04-09 15:36, Petru Rațiu wrote:
>
> Poate pentru că toolul ăla e gândit să ajute adminii de domenii care AU
> mailul hostat la gmail...
>
> On Tue, 9 Apr 2024, 15:33 Mihai Badici via RLUG, 
> wrote:
>
> On 2024-04-09 15:11, Mihai Badici via RLUG wrote:
> > WTF? SPF must allow google servers to send mails on your behalf?
> >
> > Mailul nu e, evident, hostat la gmail...
> Scuze, asta e listă de acum 20 de ani și nu permite atșamente:   :)
>
> https://toolbox.googleapps.com/apps/checkmx/check?domain=badici.ro&dkim_selector=
>
> ___
> 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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 
Problema e că îmi rejectează mailurile de la un domeniu valid cu SPF 
valid...


Încă nu sunt sigur 100% că asta  e problema dar momentan nu găsesc o 
altă explicație, iar wizardul nu îmi dă nici o altă avertizare.


Din întâmplare eu chiar am avut mailurile la gmail și de lene nu am mai 
scos directiva cu _include gmail, dar nu e cazul celorlalți.


On 2024-04-09 15:36, Petru Rațiu wrote:

Poate pentru că toolul ăla e gândit să ajute adminii de domenii care AU 
mailul hostat la gmail...


On Tue, 9 Apr 2024, 15:33 Mihai Badici via RLUG,  
wrote:



On 2024-04-09 15:11, Mihai Badici via RLUG wrote:

WTF? SPF must allow google servers to send mails on your behalf?

Mailul nu e, evident, hostat la gmail...

Scuze, asta e listă de acum 20 de ani și nu permite atșamente:   :)
https://toolbox.googleapps.com/apps/checkmx/check?domain=badici.ro&dkim_selector=

___
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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Petru Rațiu via RLUG 
Poate pentru că toolul ăla e gândit să ajute adminii de domenii care AU
mailul hostat la gmail...

On Tue, 9 Apr 2024, 15:33 Mihai Badici via RLUG,  wrote:

> On 2024-04-09 15:11, Mihai Badici via RLUG wrote:
> > WTF? SPF must allow google servers to send mails on your behalf?
> >
> > Mailul nu e, evident, hostat la gmail...
> Scuze, asta e listă de acum 20 de ani și nu permite atșamente:   :)
>
> https://toolbox.googleapps.com/apps/checkmx/check?domain=badici.ro&dkim_selector=
>
> ___
> 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

Re: [rlug] gmail requirement

2024-04-09 Fir de Conversatie Mihai Badici via RLUG 

On 2024-04-09 15:11, Mihai Badici via RLUG wrote:

WTF? SPF must allow google servers to send mails on your behalf?

Mailul nu e, evident, hostat la gmail...

Scuze, asta e listă de acum 20 de ani și nu permite atșamente:   :)
https://toolbox.googleapps.com/apps/checkmx/check?domain=badici.ro&dkim_selector=

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro