java - 我的邮件 DKIM-Signature 凭空创建一个电子邮件地址

Question

我使用 mandrill 发送使用 javamail 创建的电子邮件。当我尝试使用用户的发件人地址从我们的应用程序发送电子邮件时，DKIM 签名包含我们从未分配且不存在的电子邮件地址。当我在不使用 mandrill 的情况下发送此电子邮件时，邮件不会被更改。

问题是，当我们从使用 ourdomain.com 的 SKIM 签名的应用程序发送电子邮件时，我们为不同域 user_domain.com< 上的用户发送电子邮件。/strong>，发件人和发件人 header 设置如下:

From: Joost Schouten <joost@user_omain.com>
Sender: Joost Schouten <joost@ourdomain.com>

我们从未设置发件人 header ，电子邮件地址也不存在，不幸的是，某些邮件客户端使用此地址进行回复。它是不带域的发件人电子邮件部分和 DKIM 签名域的组合。我不知道为什么会发生这种情况以及如何阻止它发生。

DKIM 签名还提到了这个不存在的地址，因此我假设这可能是原因。不幸的是，我对所有 DKIM 文档都有些迷失，所以我希望有人能给我指出正确的方向。

这是完整的邮件:

Delivered-To: info@ourdomain.com
Received: by 10.129.137.131 with SMTP id z125csp831548ywf;
        Thu, 2 Jul 2015 13:02:36 -0700 (PDT)
X-Received: by 10.170.121.210 with SMTP id n201mr40312958ykb.97.1435867356185;
        Thu, 02 Jul 2015 13:02:36 -0700 (PDT)
Return-Path: <bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com>
Received: from mail133-7.atl131.mandrillapp.com (mail133-7.atl131.mandrillapp.com. [198.2.133.7])
        by mx.google.com with ESMTPS id 13si4642642ykz.152.2015.07.02.13.02.35
        for <info@ourdomain.com>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 02 Jul 2015 13:02:36 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com designates 198.2.133.7 as permitted sender) client-ip=198.2.133.7;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com designates 198.2.133.7 as permitted sender) smtp.mail=bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com;
       dkim=pass header.i=@ourdomain.com;
       dkim=pass header.i=@mandrillapp.com
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mandrill; d=ourdomain.com;
 h=From:Sender:Subject:To:Message-Id:Date:MIME-Version:Content-Type; i=joost@ourdomain.com;
 bh=b4xtohIO7sTTZ/geyDmOzKRydBw=;
 b=A1snz1SKxbRxJobxUqb5cxn2+s+Rj9osVXk61sJVNNc1VoVVmy7jh471byqGm7nYXGPqsL361zOE
   OPXxrdS+Zfr0Wrlhft5q6kgaJCy7xodtICXGGi6a/8xgUZ0Ko/JzWB2SI9Nqe6sMGwg5ecZDDxnt
   9u+cBHKpKBN4JY2pjEs=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=mandrill; d=ourdomain.com;
 b=FJ6zXTYOnZY/RN7okxXDpl5sNL0ysjDQfXixD8vfLk7nvpEB2Y7vUBe7EKbC0dLuHRtLSullN9Eg
   ARddkGh81Mes/ergpfyy/epulj745nOfPR8h4cQsu6dhe2p8xHA3H8AJDf2XTX8SnspuZrBgrcmU
   gXI1cSTr/QTAz6emAbE=;
Received: from pmta02.mandrill.prod.atl01.rsglab.com (127.0.0.1) by mail133-7.atl131.mandrillapp.com id himcdo1sar88 for <info@ourdomain.com>; Thu, 2 Jul 2015 20:02:35 +0000 (envelope-from <bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com>)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; 
 i=@mandrillapp.com; q=dns/txt; s=mandrill; t=1435867355; h=From : 
 Sender : Subject : To : Message-Id : Date : MIME-Version : Content-Type 
 : From : Subject : Date : X-Mandrill-User : List-Unsubscribe; 
 bh=+XtZFak4OUf8qSxm1jSRVqiU996OawoBIDsFv7gsDOM=; 
 b=UTTtcU5XeoBFrCe4v/wpBY02o5aZYRbPKWCpiKxYrrOsuqe+PqizEADb8qqkPqDKteiSOK
 K6Gz58xX1DsDGm7O6g85OX4Rqi5edA3YFVgGE4VWG7q6TxKleXsb95TXjqh/pXbUpVqH+oWn
 wnNT3PgznJFhgY0lz1njBZqvEREpg=
From: Joost Schouten <joost@user_domain.com>
Sender: Joost Schouten <joost@ourdomain.com>
Subject: Subject
Return-Path: <bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com>
Received: from [95.85.39.219] by mandrillapp.com id 0709e43ec6fc4aaaa2eaa4b9a07c553a; Thu, 02 Jul 2015 20:02:35 +0000
X-Mailer: Mailer name
To: Receiver <info@ourdomain.com>
Message-Id: <328629681.01435867315102.JavaMail.tomcat7@www>
X-Report-Abuse: Please forward a copy of this message, including all headers, to abuse@mandrill.com
X-Report-Abuse: You can also report abuse here: http://mandrillapp.com/contact/abuse?id=30191264.0709e43ec6fc4aaaa2eaa4b9a07c553a
X-Mandrill-User: md_30191264
Date: Thu, 02 Jul 2015 20:02:35 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="_av-RYsOAD_G5IlIUfcO9tyvnQ"

--_av-RYsOAD_G5IlIUfcO9tyvnQ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

PLAIN TEXT CONTENT

--_av-RYsOAD_G5IlIUfcO9tyvnQ
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body> THE HTML CONTENT</body></html>
--_av-RYsOAD_G5IlIUfcO9tyvnQ--

(编辑 - 添加了 java 代码) 我的邮件发送代码(简化)

MimeMessageHelper helper = new MimeMessageHelper(message, false);                       helper.getMimeMessage().setSubject(emailMessage.getSubject(), defaultCharSet);

helper.addTo(new InternetAddress("some@receiver.com", "Rex receiver"));             
helper.setFrom(new InternetAddress("joost@user_domain.com", "Joost Schouten"));

//commenting this next line out does not change anything
helper.getMimeMessage().setSender("no-reply@ourdomain.com");

helper.setText(htmlContentVar, true);
helper.getMimeMessage().addHeader("X-Mailer", xMailer);
helper.getMimeMessage().addHeader("X-MC-SigningDomain", "ourdomain.com");
helper.getMimeMessage().addHeader("X-MC-AutoText", "true");
helper.getMimeMessage().addHeader("X-MC-Track", "opens,clicks");
helper.getMimeMessage().addHeader("X-MC-Tags", emailMessage.getTags());

javaMailSender.send(helper.getMimeMessage());

Answer 1

问题出在 Mandrill 身上，因为他们添加了 Sender header 以确保它位于对电子邮件进行签名的域上。这里明显的问题是，当我自己在自己的域上指定它时，它们甚至会覆盖发件人 header 。目前，我们已明确添加 Reply-to header 以及 From header ，以邀请尽可能多的电子邮件客户端使用这些地址而不是 Sender 选项。这似乎确实有帮助，但我们并不完全确定这会解决所有电子邮件客户端的回复地址问题。

我希望这能让人们免于费尽心思去弄清楚到底发生了什么。这是山魈的完整答案:

Thanks for reaching out. Mandrill adds the Sender: header to your message headers to support signing and authenticating your emails when the sending domain does not have SPF and DKIM records. A few email clients (but not all) choose to display the address from this header rather than the address in the From: header.

Mandrill adds a Sender header to all emails that are sent from a domain that doesn't have SPF and DKIM set up. And we construct the Sender header address by combining the local portion of the From address (everything before the @ symbol) with the singing domain. In many cases, this can create an address that doesn't actually exist — as you've pointed out — but generally this only impacts the display of those emails and not actually email replies. You should still be able to reply to the email and have the original From: or Reply-To: address be used as the recipient of your response rather than the constructed sender header which doesn't exist.

We are looking at ways we may be able to update how we construct that header to avoid confusion, but I don't have an ETA I can offer just yet for when those changes might be available.

I hope this information was helpful. Let us know if you have any further questions.