我的邮件 DKIM-Signature 凭空创建了一个电子邮件地址
My mail DKIM-Signature creates an email address out of thin air
我使用 mandrill 发送使用 javamail 创建的电子邮件。当我尝试使用用户的发件人地址从我们的应用程序发送电子邮件时,DKIM-Signature 包含一个我们从未分配过且不存在的电子邮件地址。当我在不使用 mandrill 的情况下发送这封电子邮件时,邮件没有被更改。
问题是,当我们从我们的应用程序发送一封电子邮件时,该应用程序使用 ourdomain.com 的 SKIM 签名,并且我们为不同域中的用户发送了一封电子邮件user_domain.com,发件人和发件人headers设置如下:
From: Joost Schouten <joost@user_omain.com>
Sender: Joost Schouten <joost@ourdomain.com>
我们从未设置发件人 header,电子邮件地址也不存在,不幸的是,一些邮件客户端使用此地址进行回复。它是不带域的发件人电子邮件部分和 DKIM 签名域的组合。我不知道为什么会发生这种情况以及如何阻止它发生。
DKIM-Signature 也提到了这个不存在的地址,所以我假设这可能是原因。不幸的是,我丢失了所有 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());
问题出在 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.
我使用 mandrill 发送使用 javamail 创建的电子邮件。当我尝试使用用户的发件人地址从我们的应用程序发送电子邮件时,DKIM-Signature 包含一个我们从未分配过且不存在的电子邮件地址。当我在不使用 mandrill 的情况下发送这封电子邮件时,邮件没有被更改。
问题是,当我们从我们的应用程序发送一封电子邮件时,该应用程序使用 ourdomain.com 的 SKIM 签名,并且我们为不同域中的用户发送了一封电子邮件user_domain.com,发件人和发件人headers设置如下:
From: Joost Schouten <joost@user_omain.com>
Sender: Joost Schouten <joost@ourdomain.com>
我们从未设置发件人 header,电子邮件地址也不存在,不幸的是,一些邮件客户端使用此地址进行回复。它是不带域的发件人电子邮件部分和 DKIM 签名域的组合。我不知道为什么会发生这种情况以及如何阻止它发生。
DKIM-Signature 也提到了这个不存在的地址,所以我假设这可能是原因。不幸的是,我丢失了所有 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());
问题出在 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.