Puncte:1

De ce primesc rapoarte agregate DMARC fără erori raportate (G Suite + Amazon SES)?

drapel my

Domeniu: franzoni.eu

Un astfel de domeniu folosește G Suite (versiunea gratuită acordată) pentru a primi e-mailuri, dar din diverse motive (prefer să nu creez utilizatori pentru M2M SMTP pe G Suite și nu pot folosi SMTP pentru a trimite adrese cu alias) Am configurat Amazon SES pentru trimitere e-mail-uri; domeniul este verificat în Amazon SES, am adăugat toate înregistrările pentru DKIM și SPF.

Problema ciudată este: primesc rapoarte agregate DMARC ori de câte ori trimit e-mail prin Amazon SES.Am încercat prin Postfix de pe serverele mele și prin Gmail (am configurat un server SMTP personalizat pe contul meu personal gmail.com, folosind o identitate verificată @franzoni.eu ca alias).

Dar astfel de rapoarte nu arată nici un eșec, și DMARC-ul meu fo este setat la 1, ceea ce ar trebui să însemne trimiterea unui raport dacă a fost găsită o eroare în SPF sau DKIM. Dacă trimit un e-mail la gmail sau la alți furnizori, nici în anteturi nu găsesc erori; dkim și spf sunt „trece” peste tot.

Exemplu de raport agregat:

<?xml version="1.0"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>17723215002606464836</report_id>
    <date_range>
      <begin>1636675200</begin>
      <end>1636761599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>franzoni.eu</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>69.169.224.12 (Amazon SES)</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mercedes.franzoni.eu</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>franzoni.eu</domain>
        <result>pass</result>
        <selector>t3mfs7y2mai3am32z7ordoghte2ff3lv</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>54ecsf3zk7z4mwxwwox7z7bg6e5gwjsz</selector>
      </dkim>
      <spf>
        <domain>mailde.franzoni.eu</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Aceasta este înregistrarea DNS _dmarc.franzoni.eu:

_dmarc.franzoni.eu. 1800 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;"

Am testat trimiterea unui e-mail către unele instrumente de analiză DMARC (de ex. https://www.mail-tester.com/ ) și toți spun că DMARC-ul meu este în regulă, iar eu nu obține un raport criminalistic, chiar dacă am configurat partea ruf. Acest lucru face depanarea mai dificilă.

Orice idee despre motivul pentru care se întâmplă așa ceva ar fi apreciată.

anx avatar
drapel fr
anx
BTW, este foarte obișnuit astăzi să se conformeze dorințelor expeditorilor pentru rapoarte agregate, dar să nu trimiți niciodată criminalistică către destinații nesigure.
Puncte:1
drapel cn

Raportul agregat este generat pe baza unei perioade de timp și nu dacă a existat o eroare.

Din RFC 7489 7.2:

Vizibilitatea vine sub formă de e-mail zilnic (sau mai frecvent). Rapoarte de feedback generate de receptor care conțin date agregate despre fluxuri de mesaje relevante pentru proprietarul domeniului. Aceasta informatie include și date despre mesajele care au trecut autentificarea DMARC ca și cei care nu au făcut-o.

Un raport de eșec este generat numai atunci când există o eroare.

Din RFC 7489 7.3

Rapoartele de eșec sunt în mod normal generate și trimise aproape imediat după ce Mail Receiver detectează o eroare DMARC. Mai degrabă decât să aștepte pentru un raport agregat, aceste rapoarte sunt utile pentru rapid notificarea proprietarilor de domeniu atunci când există o eroare de autentificare. Indiferent dacă eșecul se datorează unei probleme de infrastructură sau mesajul este neautentic, rapoartele de eșec oferă și mai multe informații despre mesajul eșuat decât este disponibil într-un raport agregat.

drapel my
Mulțumesc, Paul. Deci nu am primit niciodată un eșec DMARC, acesta este adevăratul motiv pentru care nu am primit rapoarte criminalistice (=eșecuri). Nu m-am uitat niciodată direct la RFC, doar la alte resurse, inclusiv la generatoarele de înregistrări, iar distincția „medicale legale” față de „agregate” era destul de neclară. Am crezut că TOATE rapoartele sunt rapoarte de eșec, „agregatul” vs „medicina legală” fiind o modalitate de a discrimina. Lecția învățată: uitați-vă întotdeauna la specificațiile originale!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.