Come devo configurare DMARC (o DKIM?) per gestire l'inoltro OWA dei corpi email?

0

Per il mio dominio ( mydomain.com , ospitato con una G Suite gratuita), ho impostato DMARC in modalità test:

v=DMARC1; p=none; sp=reject; aspf=s; adkim=s; rua=mailto:[email protected]

Ho inviato email di prova a un gruppo di indirizzi email per capire se funziona correttamente o no, incluso il mio account Gmail personale e due indirizzi email di lavoro ( workplace.com e otherworkplace.com ) che usano Exchange / Outlook / OWA che reindirizzo al mio account Gmail personale.

DMARC convalida per tutti tranne uno dei due indirizzi di lavoro, ma solo dopo l'inoltro al mio account Gmail personale. Significa che è così che appaiono le intestazioni quando vengono ricevute sul mio posto di lavoro (interruzioni di riga modificate da me):

Authentication-Results: mx-ext2.workplace.com (amavisd-new);
    dkim=pass (2048-bit key) header.d=mydomain.com
...
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.5.16
    (mx-ext2.workplace.com [IP]); Mon, 22 Jan 2018 21:59:22 +0100 (CET)

Quando arriva la stessa mail su Gmail, questo è il risultato dell'autenticazione:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=neutral (body hash did not verify) [email protected]
       header.s=google header.b=PbtXBzel;
   spf=pass (google.com: domain of [email protected] designates WorkPlaceIP as
       permitted sender) [email protected];
   dmarc=fail (p=NONE sp=REJECT dis=NONE) header.from=mydomain.com
...
Received-SPF: pass (google.com: domain of [email protected] designates
    WorkPlaceIP as permitted sender) client-ip=WorkPlaceIP;
Authentication-Results: mx.google.com;
   dkim=neutral (body hash did not verify) [email protected]
       header.s=google header.b=PbtXBzel;
   spf=pass (google.com: domain of [email protected] designates WorkPlaceIP as 
       permitted sender) [email protected];
   dmarc=fail (p=NONE sp=REJECT dis=NONE) header.from=mydomain.com

Nota body hash did not verify e dmarc=fail .

Il corpo dell'email è vuoto, ad eccezione di alcuni tag HTML. Come ricevuto direttamente da Gmail:

Content-Type: multipart/alternative; boundary="94eb2c0d242e6d935c056363b612"

--94eb2c0d242e6d935c056363b612
Content-Type: text/plain; charset="UTF-8"



--94eb2c0d242e6d935c056363b612
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--94eb2c0d242e6d935c056363b612--

Come ricevuto da Gmail tramite un'altra email sul posto di lavoro:

Content-Type: multipart/alternative; boundary="f403045f58c6ca3863056363b147"
X-MS-Exchange-Inbox-Rules-Loop: [email protected]

--f403045f58c6ca3863056363b147
Content-Type: text/plain; charset="UTF-8"



--f403045f58c6ca3863056363b147
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--f403045f58c6ca3863056363b147--

Come ricevuto da Gmail tramite l'email di lavoro non funzionante:

Content-Type: multipart/alternative;
    boundary="_000_3b36ca239c7e4763redacted_"
MIME-Version: 1.0

--_000_3b36ca239c7e4763redacted_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



--_000_3b36ca239c7e4763redacted_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <[email protected]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body>
<div dir=3D"ltr"><br>
</div>
</body>
</html>

--_000_3b36ca239c7e4763redacted_--

Quindi workplace.com sta cambiando non solo il charset , che non dovrebbe essere un grosso problema a causa della normalizzazione prima del calcolo della firma DKIM; ma anche il corpo introducendo tag HTML extra negli allegati. otherworkplace.com sembra non farlo.

workplace.com sembra utilizzare OWA 2013 (e quindi Exchange Server 2013), mentre otherworkplace.com sembra utilizzare una versione più recente, a giudicare dall'interfaccia utente.

Il mio takeaway è quello

  • Potrei chiedere alle persone IT del mio ambiente di lavoro di vedere cosa potrebbe fare il server di Exchange (e magari farli smettere), ma
  • Non riesco a controllare tutti i server di Exchange nel mondo, e farmi fare qualcosa di simile nel mio piccolo campione rende questo un probabile problema per colpire in altri posti, non appena le persone inoltrano email dall'indirizzo email di Exchange / OWA.

Quindi, come dovrei riconfigurare le mie impostazioni DMARC per la massima sicurezza, pur mantenendo una compatibilità ragionevolmente elevata?

    
posta bers 03.02.2018 - 11:11
fonte

1 risposta

1

TL; DR: Questo non è un problema di una configurazione DMC non sicura. L'errore DMARC che vedi è dovuto a una firma DKIM danneggiata. La firma DKIM è stata interrotta a causa di un server di posta nel percorso che non supportava 8BITMIME. Correggere è assicurarsi di avere una posta solo ASCII prima di applicare la firma DKIM sul proprio server. Ho descritto il problema in modo più dettagliato in Rompere DKIM per caso .

DMARC passa se passa SPF o DKIM. Passando significa per SPF nel contesto di DMARC che l'indirizzo IP di origine è quello previsto e che il mittente in base alla busta SMTP corrisponde al mittente in base alla busta Rfc822 (cioè, dall'intestazione nella posta). Per il passaggio DKIM significa che la firma DKIM è corretta e che il dominio nella firma DKIM corrisponde al dominio dell'intestazione From nella posta.

Se invii i messaggi direttamente dal tuo dominio, SPF passerà e quindi il risultato di DKIM non ha importanza. Se invece reindirizzi la posta attraverso un altro server, SPF non passerà più e il risultato DMARC dipende solo da DKIM.

La firma DKIM include un hash sul corpo della posta. Questo hash viene creato dal codice sorgente del corpo come visualizzato dal server di firma. Qualsiasi modifica al corpo durante il trasporto invaliderà quindi la firma.

Sfortunatamente, tali cambiamenti possono verificarsi se un server di posta supporta l'input a 8 bit (estensione SMTP 8BITMIME) ma il server di posta dell'hop successivo non lo supporta. In questo caso, tutti i dati a 8 bit nel corpo devono essere ricodificati in modo che il corpo sia solo ASCII. E questo è ciò che accade nel tuo caso: un server di posta sul percorso non supporta 8BITMIME e quindi il server di posta mittente ricodificherà la posta con Content-Transfer-Encoding: quoted-printable . Ma questo interrompe le firme DKIM esistenti e quindi DKIM fallirà.

Dal momento che di solito non è possibile controllare il percorso che la posta utilizza Internet e se tutti i server di posta nel percorso supportano 8BITMIME è necessario assicurarsi che la posta sia già solo ASCII prima che venga creata la firma DKIM. Solo in questo modo è possibile assicurarsi che non si verifichi una rottura della firma DKIM dovuta alla ricodifica successiva. Il modo più semplice per farlo potrebbe essere configurare il proprio server di posta per non accettare 8BITMIME e quindi forzare qualsiasi mittente a ricodificare la posta in ASCII-solo prima di essere inviata al server. Per il server di posta postfix l'opzione rilevante è il parametro smtputf8_enable .

Per ulteriori informazioni vedi Rompere DKIM per caso dove Descrivo questo problema in modo più dettagliato.

    
risposta data 03.02.2018 - 11:47
fonte

Leggi altre domande sui tag