Puncte:1

DMARC eșec pentru raportul de livrare

drapel us

Am un server de e-mail bazat pe Docker (Mailu) înființat. Funcționează excelent, cu excepția rapoartelor de livrare care sunt trimise automat (una dintre căsuțele poștale ale utilizatorilor este plină și o notificare „Cotă depășită” este trimisă expeditorului).

Rapoartele sunt respinse de destinatar din cauza eșecului DMARC:

Acesta este un raport de abuz prin e-mail pentru un mesaj de e-mail primit de la IP xxx.xxx.xxx.xxx pe Mar, 28 septembrie 2021 05:16:31 +0000. Mesajul de mai jos nu a respectat politica dmarc a domeniului de trimitere.

Antetul mesajului respins:

Tip de feedback: eșec de autentificare
User-Agent: Lua/1.0
Versiune: 1.0
E-mail-original-de la: 
Original-Rcpt-To: [email protected]
Data sosirii: marți, 28 septembrie 2021 05:16:31 +0000
ID-ul mesajului: <[email protected]>
Rezultate autentificare: dmarc=fail (p=reject; dis=reject) header.from=domainB.com
IP-sursă: xxx.xxx.xxx.xxx
Livrare-Rezultat: respingere
Auth-Failure: dmarc
Domeniu raportat: domainB.com

Serverul de e-mail rulează mail.domainB.com, are domeniuA.com configurat, iar e-mailul este trimis la [email protected].

SPF este configurat pentru ambele domenii:

  • Domeniul A: v=spf1 a mx include:domainB.com -all
  • Domeniul B: v=spf1 a mx include:_spf.google.com include:servers.mcsv.net include:relay.mailchannels.net -all

DMARC pentru ambele: v=DMARC1;p=reject;rua=mailto:[email protected];ruf=mailto:[email protected];adkim=s;aspf=s;fo=1;

MX pentru ambele domenii este mail.domainB.com iar înregistrarea PTR pentru IP-ul „xxx.xxx.xxx.xxx” indică srv.domainB.com. Toate domeniile rulează și indică același server.

Bănuiesc o eroare de configurare DNS/DMARC, dar nu o pot semnala. Trebuie să includ domeniul domeniuB.com și în SPF (vezi antet.form).

Editare: Unele mesaje conțin un corp de mesaj (în plus față de antetul de mai sus):

Received-SPF: None (fără înregistrare SPF) identitate = fără înregistrare SPF; client-ip=xxx.xxx.xxx.xxx; helo=mail.domainB.com; plic-de la=<>; receptor=<NECUNOSCUT> 
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.hostpark.net F224D16527
Primit: prin mail.domainB.com (Postfix)
    id 61B3BDFF1; Miercuri, 29 septembrie 2021 06:16:50 +0000 (UTC)
Data: miercuri, 29 septembrie 2021 06:16:50 +0000 (UTC)
De la: [email protected] (sistem de livrare a corespondenței)
Subiect: e-mail nelivrat returnat expeditorului
Către: [email protected]
Trimis automat: răspuns automat
Versiunea MIME: 1.0
Tip de conținut: mai multe părți/raport; tip-raport=starea-livrare;
    boundary="25F89DFEB.1632896210/mail.domainB.com"
ID-ul mesajului: <[email protected]>

Poate cineva să mă îndrume în direcția corectă? Foarte apreciat, multumesc!

sebix avatar
drapel ie
`e-mailul este trimis la [email protected]` Presupun că e-mailul este trimis *de la* [email protected] *la* [email protected]?
drapel us
@sebix E-mailul original a fost un e-mail de la Linkedin. Deoarece căsuța poștală a utilizatorului este plină, serverul de e-mail (Mailu) trimite o revenire la `[email protected]`. După definiție, FROM-ul săriturii este gol, presupun sau `domainA.com` ca `header.form`, să bănuim. Pe măsură ce nu reușește DMARC, respingerea este respinsă.
Puncte:1
drapel us

Remedierea părea a fi destul de ușoară. Înregistrarea SPF a avut mai mult de 10 căutări și, prin urmare, a fost corectă din punct de vedere sintetic, dar a fost interpretată ca nevalidă. Soluția a fost eliminarea unuia dintre include:.

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.