(devido a problema com o filtro de spam SO, alguns nomes foram substituídos)
Contexto: temos um pequeno servidor (cerca de 50 usuários, referenciados como metalab.ifmoru nos registros abaixo), permitimos um redirecionamento para serviços externos, por exemplo, gmailcom. Ainda assim, usamos uma configuração com dois servidores: Edge (diretamente conectado à Internet) e Mailbox (atrás do firewall) usando o Microsoft Exchange 2013. Temos registros SPF e DKIM corretos, com pontuação 10 de 10 no mail-tester. Para casos da vida real, a entrega de saída é boa, nada foi relatado, exceto ...
O problema: Alguns remetentes externos (mailru em logs abaixo, Yahoo nesta lista também) usam uma política DMARC rígida e o redirecionamento via nosso servidor é rejeitado com uma mensagem de erro típica como esta: p>
mx.google.com returns an error message:
Unauthenticated email from mailru is not accepted due to domain's DMARC policy. Please contact the administrator of mailru domain if this was a legitimate mail. Please visit cut some link to google to learn about the DMARC initiative. 62si7948506lfu.198 - gsmtp
Investigação: Por definição de dmarc.org
A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message.
Para verificar o SPF e o DKIM mais uma vez, envio uma mensagem para a minha caixa de entrada do google. Tudo bem, todos eles têm:
Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=pass (google.com: domain of [email protected] designates 77.234.203.179 as permitted sender) [email protected];
dmarc=pass (p=NONE dis=NONE) header.from=metalab.ifmoru
Ok, vamos verificar o cabeçalho da mensagem redirecionada de outros servidores, sem uma política DMARC rígida. Às vezes, se parece estar bem também:
Received-SPF: pass (google.com: domain of [email protected] designates 192.30.252.199 as permitted sender) client-ip=192.30.252.199;
Authentication-Results: mx.google.com;
dkim=pass (test mode) [email protected];
spf=pass (google.com: domain of [email protected] designates 192.30.252.199 as permitted sender) [email protected];
dmarc=pass (p=NONE dis=NONE) header.from=github.com
No entanto, às vezes, FALHA devido à parte DKIM:
Authentication-Results: mx.google.com;
dkim=pass [email protected];
dkim=neutral (body hash did not verify) header.i=@gmailcom;
spf=pass (google.com: domain of [email protected] designates 77.234.203.179 as permitted sender) [email protected];
dmarc=fail (p=NONE dis=NONE) header.from=gmailcom
Experiência:
1) Configure o redirecionamento para o google do nosso servidor (metalab.ifmoru) para gmailcom
2) Configure o redirecionamento para o google do servidor Zimbra (algum outro endereço) para o gmailcom
3) Envie uma única carta de mailru com os endereços mencionados acima no campo From .
O resultado: O redirecionamento através do nosso servidor é rejeitado, redirecionando a passagem Zimbra vai bem. Ao verificar os cabeçalhos SMTP eu encontrei o mesmo bloco de cabeçalho para 1) mensagem na caixa de entrada em nosso servidor 2) no servidor Zimbra 3) em mensagem redirecionada vinda do Zimbra. Aqui 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__ =?= <[email protected]>
Cc: =?UTF-8? __cut__ =?= <[email protected]>
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__ [email protected]>
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__ [email protected]>
References: <CADQ __cut__ [email protected]>
como para a mensagem rejeitada a mesma parte parece muito diferente - a ordem foi alterada, alguns UTF-8 listrados no cabeçalho, alguns convertidos em codificação koi-8, a ortografia de tags x foi alterada de Camel-Case para inferior, etc .:
From: =?koi8-r? __cut__ =?= <XXXXXXXXXXXXX@mailru>
To: Kon __cut__ nko <[email protected]>
CC: Kon __cut__ nko <[email protected]>
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__ [email protected]>
References: <CADQB __cut__ [email protected]>
In-Reply-To: <CADQB __cut__ [email protected]>
Reply-To: =?koi8-r? __cut__ ==?= <XXXXXXXXXXXXX@mailru>
X-MS-Has-Attach:
X-MS-Exchange-Inbox-Rules-Loop: [email protected]
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 o MS Exchange quebra o DKIM reescrevendo os cabeçalhos. Então o pergunta é: Como preservar cabeçalhos de serem reescritos durante o redirecionamento via MS Echange?
Tentativas iniciais:
1) A assinatura DKIM do remetente foi quebrada em um ambiente do Exchange Server 2013, a CU6 deve resolver o problema. Não ajuda. Usando CU9 no momento.
2) Adicione ms-Exch-Send-Headers-Routing ao envio de conectores. Controla a preservação de cabeçalhos RECEBIDOS em mensagens. Não ajuda.
verificado com:
PS C:\Windows\system32> Get-SendConnector | Get-ADPermission | where {$_.ExtendedRights -like "*routing*"} | fl user, extendedrights
Links adicionais Não há boa reputação para postar. Palavras-chave para pesquisa