(debido a un problema con el filtro de spam SO, algunos nombres fueron reemplazados)
Antecedentes: tenemos un servidor pequeño (alrededor de 50 usuarios, referido como metalab.ifmoru en los registros a continuación), permitimos hacer una redirección a servicios externos, por ejemplo, gmailcom. Aún así, utilizamos una configuración con dos servidores: Edge (conectado directamente a Internet) y Buzón (detrás del firewall) con Microsoft Exchange 2013. Tenemos un registro correcto de SPF y DKIM, con un puntaje de 10 de 10 en el probador de correo. Para casos de la vida real, la entrega saliente está bien, no se informó nada excepto ...
El problema: algunos remitentes externos (mailru en los registros a continuación, Yahoo en esta lista también) usan una estricta política DMARC y la redirección a través de nuestro servidor se rechaza con un mensaje de error típico como este:
mx.google.com devuelve un mensaje de error:
El correo electrónico no autenticado de mailru no se acepta debido a la política DMARC del dominio. Póngase en contacto con el administrador del dominio mailru si se trata de un correo legítimo. Visite cortar algún enlace a google para obtener información sobre la iniciativa DMARC. 62si7948506lfu.198 - gsmtp
Investigación: por definición de dmarc.org
Una política DMARC le permite al remitente indicar que sus mensajes están protegidos por SPF y / o DKIM, y le dice al receptor qué hacer si ninguno de esos métodos de autenticación pasa, como basura o rechazar el mensaje.
Para verificar SPF y DKIM una vez más, envío un mensaje a mi bandeja de entrada de Google. Se ve bien, todos tienen:
Authentication-Results: mx.google.com;
dkim=pass header.i=@metalab.ifmoru;
spf=pass (google.com: domain of XXXXXXX@metalab.ifmoru designates 77.234.203.179 as permitted sender) smtp.mailfrom=XXXXXXXX@metalab.ifmoru;
dmarc=pass (p=NONE dis=NONE) header.from=metalab.ifmoru
Ok, verifiquemos el encabezado del mensaje redirigido desde otros servidores, sin una estricta política DMARC. A veces, si parece estar bien también:
Received-SPF: pass (google.com: domain of noreply@github.com designates 192.30.252.199 as permitted sender) client-ip=192.30.252.199;
Authentication-Results: mx.google.com;
dkim=pass (test mode) header.i=@github.com;
spf=pass (google.com: domain of noreply@github.com designates 192.30.252.199 as permitted sender) smtp.mailfrom=noreply@github.com;
dmarc=pass (p=NONE dis=NONE) header.from=github.com
Sin embargo, a veces FALLA debido a la parte DKIM:
Authentication-Results: mx.google.com;
dkim=pass header.i=@metalab.ifmoru;
dkim=neutral (body hash did not verify) header.i=@gmailcom;
spf=pass (google.com: domain of XXXXXXXXXX@metalab.ifmoru designates 77.234.203.179 as permitted sender) smtp.mailfrom=XXXXXXXXXXXX@metalab.ifmoru;
dmarc=fail (p=NONE dis=NONE) header.from=gmailcom
Experimentar:
1) Configuración de redireccionamiento a google desde nuestro servidor (metalab.ifmoru) a gmailcom
2) Configuración de redireccionamiento a google desde el servidor Zimbra (alguna otra dirección) a gmailcom
3) Enviar una sola carta de mailru con las direcciones mencionadas en el Fromcampo.
El resultado: la redirección a través de nuestro servidor es rechazada, la redirección que pasa Zimbra va bien. Mientras revisaba los encabezados SMTP, encontré el mismo bloque de encabezado para 1) mensaje en la bandeja de entrada en nuestro servidor 2) en el servidor Zimbra 3) en el mensaje redirigido proveniente de Zimbra. Aquí está:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailru; s=mail2;
h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=rZNB __cut__ znAs=;
b=pIZR __cut__ A8aE=;
Received: from [84.204.20.115] (ident=mail)
by f96.i.mailru with local (envelope-from <XXXXXXXXX@mailru>)
id 1byY2P-0005Ep-6D; Mon, 24 Oct 2016 08:43:09 +0300
Received: from [84.204.20.115] by e.mailru with HTTP;
Mon, 24 Oct 2016 08:43:09 +0300
From: =?UTF-8? __cut__ 0=?= <XXXXXXXXXXXXX@mailru>
To: =?UTF-8? __cut__ =?= <XXXXXXXXXXXXX@metalab.ifmoru>
Cc: =?UTF-8? __cut__ =?= <XXXXXXXXXXXXX@corp.ifmoru>
Subject: =?UTF-8 __cut__ =?=
MIME-Version: 1.0
X-Mailer: mailru Mailer 1.0
X-Originating-IP: [84.204.20.115]
Date: Mon, 24 Oct 2016 08:43:09 +0300
Reply-To: =?UTF-8?B?0JDQudGA0Y0=?= <XXXXXXXXXXXXX@mailru>
X-Priority: 3 (Normal)
Message-ID: <147 __cut__ 947@f96.i.mailru>
Content-Type: multipart/alternative;
boundary="--ALT--biYZ __cut__ 7789"
X-95568C8E: 26815A __cut__ 65AEC6
X-E1FCDC63: 1787D815 __cut__ 84B93
X-E1FCDC64: FAAF71 __cut__ 93F4C0D9
X-Mailru-Sender: D211C __cut__ DD1EA8939684724DAF05A372A3159
X-Mras: OK
X-Spam: undefined
In-Reply-To: <CADQB __cut__ u2f3A@mail.gmailcom>
References: <CADQ __cut__ 3A@mail.gmailcom>
En cuanto al mensaje rechazado, la misma parte se ve muy diferente: se cambió el orden, algunos encabezados seccionaron UTF-8, algunos se volcaron a la codificación koi-8, la ortografía de las etiquetas x se cambió de Camel-Case a inferior, etc.
From: =?koi8-r? __cut__ =?= <XXXXXXXXXXXXX@mailru>
To: Kon __cut__ nko <XXXXXXXXXXXXX@metalab.ifmoru>
CC: Kon __cut__ nko <XXXXXXXXXXXXX@corp.ifmoru>
Subject: =?koi8-r? __cut__ ?=
Thread-Topic: =?koi8-r?B __cut__ ?=
Thread-Index: AQHSLb __cut__ 65w==
Date: Mon, 24 Oct 2016 05:43:09 +0000
Message-ID: <0c14 __cut__ c21@post.metalab.ifmoru>
References: <CADQB __cut__ 2f3A@mail.gmailcom>
In-Reply-To: <CADQB __cut__ 2f3A@mail.gmailcom>
Reply-To: =?koi8-r? __cut__ ==?= <XXXXXXXXXXXXX@mailru>
X-MS-Has-Attach:
X-MS-Exchange-Inbox-Rules-Loop: XXXXXXXXXXXXX@metalab.ifmoru
X-MS-TNEF-Correlator:
dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailru;
s=mail2;
h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From;
bh=rZNBy4 __cut__ nAs=;
b=pIZRm8 __cut__ IA8aE=;
x-mailer: mailru Mailer 1.0
x-originating-ip: [84.204.20.115]
authentication-results: f96.i.mailru; auth=pass smtp.auth=XXXXXXXXXXXXX@mailru
smtp.mailfrom=XXXXXXXXXXXXX@mailru
x-95568c8e: 26815 __cut__ 5AEC6
x-e1fcdc63: 1787 __cut__ 4B93
x-e1fcdc64: FAA __cut__ C0D9
x-mailru-sender: D2 __cut__ 3159
x-mras: OK
x-spam: undefined
Parece que MS Exchange incumple DKIM reescribiendo los encabezados. Entonces la pregunta es: ¿Cómo evitar que los encabezados se reescriban durante la redirección a través de MS Echange?
Intentos iniciales
1) La firma DKIM del remitente se rompió en un entorno de Exchange Server 2013, CU6 debería resolver el problema. No ayuda Usando CU9 en este momento.
2) Agregar ms-Exch-Send-Headers-Routinga los conectores de envío. Controla la preservación de los encabezados RECIBIDOS en los mensajes. No ayuda
Comprobado con:
PS C:\Windows\system32> Get-SendConnector | Get-ADPermission | where {$_.ExtendedRights -like "*routing*"} | fl user, extendedrights
Enlaces de adición No hay suficiente reputación para publicar. Palabras clave para búsqueda
- Encabezado firewall Exchange 2013
- Cómo eliminar la información de enrutamiento interno de los encabezados en Exchange
- Exchange 2013: aplicación del firewall de encabezado
- Uso de reescritura de encabezado con Exchange Server
- Reescritura de direcciones en servidores de transporte perimetral