DMARC / SPF / DKIM - inoltra le email di quarantena a un indirizzo email separato

Question

DMARC / SPF / DKIM - inoltra le email di quarantena a un indirizzo email separato

#1 da (1 voti)
#2 da (0 voti)

2

C'è un modo con DMARC / SPF / DKIM per inoltrare tutte le email che non riescono a DMARC a un indirizzo e-mail che ho specificato?

Vale a dire, se qualcuno cerca di falsificare un'e-mail dicendo che proviene da me, e fallisce, vorrei che quell'e-mail fosse inviata a un indirizzo e-mail che specificavo piuttosto che a chi l'avessero voluto.

È qualcosa che può essere fatto?

Ho eseguito RUF / RUA per un mese ora, con impostazioni diverse per ottenere rapporti su quali servizi di terze parti aggiornare. Tuttavia, sto ancora ottenendo alcuni tentativi di spoofing dal Medio Oriente / Asia. Sto cercando di ottenere tutte le email che non riescono a inviare DMARC a uno specifico indirizzo email che ho specificato, piuttosto che essere inviato all'utente finale (spam) o bloccato.

Utilizziamo Google Apps per il nostro server di posta elettronica.
Tutte le informazioni sul dominio (record TXT) sono memorizzate su Route 53 su AWS.

Dal nostro rapporto RUF vedrò una voce come questa:

  <record>
    <row>
      <source_ip>45.123.219.46</source_ip>
      <count>14</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>****.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>***.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

In questo caso, sarebbe interessante sapere cosa è stato inviato.

email dmarc

posta Ryan Ternier 22.08.2017 - 17:48

fonte

2 risposte

Leggi altre domande sui tag email dmarc

LPORT question - Mi sembra di non capire alcuni concetti Load balancer haproxy [chiuso]

score 1 · Answer 1

Una ricerca rapida mostra Rapporti sui guasti DMARC .

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.
_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:[email protected]"
Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.
_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Nota l'avviso nella parte superiore della sezione, anche se vuoi effettivamente farlo:

Not until you have read this answer and made sure you are ready to receive a LOT of messages...

Modifica: ho letto male la wiki, sembra che i rapporti RUF possano includere l'intera email, ma non necessariamente.

Ovviamente, fino al server che convalida DKIM e SPF per decidere cosa fare in caso di errore, DMARC sta essenzialmente chiedendo ai server "potresti trattare gli errori di convalida in un certo modo", e RUF chiede "se una email fallisce convalida, potresti dirmi perché? ", ma è possibile che alcuni server non si preoccupino di darti un rapporto o che il rapporto non includa tutto ciò che desideri. Se vogliono ignorare la tua richiesta non c'è molto che puoi fare.

score 0 · Answer 2

Visualizzi i record DMARC con gli indirizzi di segnalazione dannosi ? (Questi sono rua= e ruf= per i rapporti aggregati e completi). Se è così, sarei molto interessato a vederli. Non mi preoccupo molto di questo come un vettore di attacco poiché questi report sono banali da bloccare e i messaggi progettati per attivare un volume DDoS di rapporti completi su una vittima di questo tipo finirebbero col mettere in difficoltà l'aggressore.

L'intero punto degli indirizzi di segnalazione DMARC è di consentire al proprietario (legittimo) del dominio di invio (presumibilmente) di vedere chi sta forgiando la posta, che aiuta a identificare legittimi server configurati in modo errato (ad esempio una filiale di marketing) e allo spoofing tentativi. Nessuna implementazione DMARC saggia (aziendale) utilizza p=reject fino a quando i rapporti suggeriscono che è sicuro.

Google non sembra includere i risultati DMARC nelle intestazioni dei risultati di autenticazione, altrimenti potresti raccoglierla e creare la tua copia del rapporto. Tuttavia, hai già eluso la tua infrastruttura di posta elettronica.

Un filtro come procmail sarebbe in grado di scrivere una ricetta come questa:

:0c
^Authentication-Results: mx\.google\.com;[^A-Z]*dkim=[^p]
! [email protected]

Questo cerca l'intestazione Authentication-Results aggiunta da mx.google.com e vede se ha testato DKIM ma non ha visto una firma valida (che sarebbe dkim=pass ). In tal caso, inoltra una copia a [email protected]. (Rendi la prima riga :0 per impedire la consegna anziché copiare il messaggio.)

Si noti che questo corrisponde a un errore DKIM e non a un errore DMARC. Credo che DMARC p=reject di errori non ti sarà mai stato fornito da Google, quindi probabilmente non puoi intercettare i rapporti.