[dmarc-discuss] Anything to be done about DMARC failures caused by internal Microsoft forwards?

[Jonathan Kamens via dmarc-discuss]

I finally got a couple DMARC failure reports this morning -- the first
two failure reports I've received -- and they're false DMARC failures
for legitimate emails that apparently will be bounced incorrectly if we
turn on p=reject.

In both cases, we were emailing someone (through MailChimp) with a
live.com email address. Our SPF and DKIM both passed when outlook.com
(which handles email for live.com) received the message. Then, however,
the message was forwarded from outlook.com to hotmail.com, and
hotmail.com reported it as a DMARC failure.

I have no way of knowing whether this is because the user has both
live.com and hotmail.com accounts and configured the former to forward
to the latter, or whether in fact all live.com emails are forwarded
internally by Microsoft to hotmail.com.

I've appended the bounce report and message headers from one of the
bounced messages below.

Can we do anything to prevent messages such as this one from bouncing
when we turn on p=reject?

Thanks,

Jonathan Kamens

Here's the bounce report:

Feedback-Type: auth-failure
User-Agent: XMR/2.2
Version: 1.0
Original-Mail-From: <***@quantopian.com>
Arrival-Date: Thu, 13 Jul 2017 05:02:03 -0700
Message-ID:
<***@mail220.atl61.mcsv.net>
Authentication-Results: hotmail.com; spf=fail (sender IP is 40.92.4.105;
identity alignment result is pass and alignment mode is relaxed)
smtp.mailfrom=***@quantopian.com; dkim=fail (identity alignment
result is pass and alignment mode is relaxed) header.d=quantopian.com;
x-hmca=fail header.id=***@quantopian.com
Source-IP: 40.92.4.105
Auth-Failure: spf
Reported-Domain: quantopian.com
DKIM-Domain: quantopian.com
DKIM-Identity: ***@quantopian.com
DKIM-Selector: k1

Here are the message headers. I'm sure most of them are irrelevant, but
I've left everything because I'm not 100% what might and might not be
useful:

Authentication-Results: hotmail.com; spf=fail (sender IP is 40.92.4.105;
identity alignment result is pass and alignment mode is relaxed)
smtp.mailfrom=***@quantopian.com; dkim=fail (identity alignment
result is pass and alignment mode is relaxed) header.d=quantopian.com;
x-hmca=fail header.id=***@quantopian.com
X-Envelope-Sender: ***@quantopian.com
X-SID-PRA: ***@quantopian.com
X-AUTH-Result: FAIL
X-SID-Result: FAIL
Received: from NAM02-CY1-obe.outbound.protection.outlook.com
([40.92.4.105]) by SNT004-MC6F1.hotmail.com over TLS secured channel
with Microsoft SMTPSVC(7.5.7601.23143);
Thu, 13 Jul 2017 05:02:03 -0700
Received: from SN1NAM02FT046.eop-nam02.prod.protection.outlook.com
(10.152.72.59) by SN1NAM02HT242.eop-nam02.prod.protection.outlook.com
(10.152.73.41) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1220.9; Thu, 13
Jul 2017 12:01:57 +0000
Received: from CY4PR2001MB1847.namprd20.prod.outlook.com (10.152.72.54) by
SN1NAM02FT046.mail.protection.outlook.com (10.152.72.191) with
Microsoft SMTP
Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1240.9 via Frontend Transport; Thu, 13 Jul 2017 12:01:57 +0000
Received: from CY4PR2001MB1847.namprd20.prod.outlook.com ([127.0.0.1]) by
CY4PR2001MB1847.namprd20.prod.outlook.com ([10.171.214.15]) with Microsoft
SMTP Server id 15.01.1240.020; Thu, 13 Jul 2017 12:01:57 +0000
From: Kelly Elmstrom <***@quantopian.com>
To: "REDACTED" <***@outlook.com>
Subject: Don't Miss the Quantopian Events in Seattle this Week
Thread-Topic: Don't Miss the Quantopian Events in Seattle this Week
Date: Thu, 13 Jul 2017 12:01:51 +0000
Message-ID:
<***@mail220.atl61.mcsv.net>
List-Unsubscribe:
<http://quantopian.us5.list-manage.com/unsubscribe?u=4c1d0cf4959586b47ef210e9c&id=7cca55778a&e=d34ffee5e0&c=6fecbb115c>,
<mailto:unsubscribe-mc.us5_4c1d0cf4959586b47ef210e9c.6fecbb115c-***@mailin1.us2.mcsv.net?subject=unsubscribe>
Reply-To: Kelly Elmstrom <***@quantopian.com>
X-MS-Has-Attach:
X-MS-Exchange-Inbox-Rules-Loop: [REDACTED]
X-MS-TNEF-Correlator:
authentication-results: spf=pass (sender IP is 205.201.135.220)
smtp.mailfrom=mail220.atl61.mcsv.net; live.com; dkim=pass (signature was
verified) header.d=quantopian.com;live.com; dmarc=pass action=none
header.from=quantopian.com;
received-spf: Pass (protection.outlook.com: domain of mail220.atl61.mcsv.net
designates 205.201.135.220 as permitted sender)
receiver=protection.outlook.com; client-ip=205.201.135.220; helo=
mail220.atl61.mcsv.net;
x-incomingtopheadermarker:
OriginalChecksum:BA85BFE3DA5687159ECBDF6BCC7014F3FDC727FEBF2BD8223B58DB3FBCD4ECAD;UpperCasedChecksum:CB294777FAAF9F767FCD2A1D612E88117F017CC9C14DD8F25C933E42F8F72DC2;SizeAsReceived:2369;Count:24
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1;
d=quantopian.com;
h=Subject:From:Reply-To:To:Date:Message-ID:List-ID:List-Unsubscribe:
Content-Type:MIME-Version; i=***@quantopian.com;
bh=fDDC6i/MTFX2fZe+gjuYKbYoZZS/MeyDpfQSfNPCg+c=;
b=sYYINiy3JzTRoF4g2sSCLTnycEJUVPJvesDiM5Nk/F/X2gLFVJeO75MsPmuapP1oT1n6xvNFesHr

7r1N61LXtWkagZoH4cT70aP8uShLi6LAAPG9tBiRat5vah40x271Wjb4rlE8Zyfiy0gbNd3F/Tkc
OcoSjjxxiWSotHhdh9g=
x-mailer: MailChimp Mailer - **CID6fecbb115cd34ffee5e0**
x-campaign: mailchimp4c1d0cf4959586b47ef210e9c.6fecbb115c
x-campaignid: mailchimp4c1d0cf4959586b47ef210e9c.6fecbb115c
x-report-abuse: Please report abuse for this campaign here:
http://www.mailchimp.com/abuse/abuse.phtml?u=4c1d0cf4959586b47ef210e9c&id=6fecbb115c&e=d34ffee5e0
x-mc-user: 4c1d0cf4959586b47ef210e9c
feedback-id: 11246039:11246039.669585:us5:mc
list-id: 4c1d0cf4959586b47ef210e9cmc list
<4c1d0cf4959586b47ef210e9c.51129.list-id.mcsv.net>
x-accounttype: pd
list-unsubscribe-post: List-Unsubscribe=One-Click
x-mcda: FALSE
x-originalarrivaltime: 13 Jul 2017 12:01:55.0746 (UTC)
FILETIME=[D29CD020:01D2FBCF]
x-incomingheadercount: 74
x-eopattributedmessage: 1
x-eoptenantattributedmessage: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa:0
cmm-sender-ip: 205.201.135.220
cmm-sending-ip: 205.201.135.220
cmm-authentication-results: hotmail.com; spf=pass (sender IP is
205.201.135.220; identity alignment result is fail and alignment mode is
relaxed)
smtp.mailfrom=bounce-mc.us5_11246039.669585-[REDACTED]@mail220.atl61.mcsv.net;
dkim=pass (identity alignment result is pass and alignment mode is relaxed)
header.d=quantopian.com; x-hmca=pass header.id=***@quantopian.com
cmm-x-sid-pra: ***@quantopian.com
cmm-x-auth-result: PASS
cmm-x-sid-result: PASS
cmm-x-message-status: n:n
cmm-x-message-delivery: Vj0xLjE7dXM9MDtsPTE7YT0xO0Q9MTtHRD0xO1NDTD0w
cmm-x-message-info:
NhFq/7gR1vQgiyfVu7hHjX7cEIYUGy9ouVv27+kUvOh+yT9R6U8S694jjriTSk6ax/qvBdv+DTZmeVqcMniXZ3Y9aVKmfyQuSdonHbwSn1bdiAFvbAgTAZsA2rLNg5/1ItACMdFg3tujsw/TO2XSDArnCj8YxbXIfN/ynuETGNw96wF4BVIGxT9NbjbN1urGJncvJFgHXO2p4RsOxdCq3uPjhKnJIOatLy0Sb8QC515gdGL0iskb3yq6YCIav7/p
x-microsoft-exchange-diagnostics:
1;SN1NAM02HT242;7:G4L9jHxiJKN4Cf8ouwQX/MT6S88IVIqK+T0ClcAezjD3UKZl7SwqfOWfqk89MABbuUQubb4163Qc0t/zDHCiCpU2SYAZq4FFhyJ3Eh0J/pcg6PUWiOpBwCDKsHPV2osLohgq3hX7kFKV2bJP41RXTmQKUChtq5RCA9xEJHr/IOR94bNfFf6vQMwcoFNORDqYyDBPGZwZKvzOh323UbRlNEPrW2oyNjkF//IMrVeD0kraM3ajyZzA9u/CxmjeBBTafcxCwmEr3halV1+q9oOklhBWvIMRsuh8ZjALwZkh4Ns8YRUMiZsTPeXgXDRP0Pt+JvY6vpOHoNd67KRDZcog/O+WE7vtuSfGd0rOmZH2p0uBfxsIYYetB8kChqrknwV2IgDLW0OC1gQ46d9F5IEfYg/QWq8Q2uZWIwKxNT7iYhYIiHhcbUo7R6OYhOwpnSz8sMBpF02p6ZI/zqhxKog6OX32m2xXBh9kRvLBXqKC7Y7dmofwt+iV32zgD6jyWO5MxyEjZyMBypbNftEur7K3H1NkGtPofYAaHKyvLBZ8eic6IiQbrD3Z2gx9AgLr08u8d1XYCCDMbuPTWpdLAYG4dxoXC/kLcJ9ZeyCr1dAUVMzzu4kJorolCFxXLLcEZEc7JxibW0+KlNkY7Ccb3XreQxq0+HXHz2R8moLjT9QYgb3tK+qLhmv3tZ2jx/JvOQecCs5vSJzCIciN2hsi5yxU82K2LBuJo9gfgshfI/Sl1K21MYSogngUjq4ZvY1sJu+HfayyzKlu0IScQMJEafsjbQ==
x-forefront-antispam-report:
EFV:NLI;SFV:NSPM;SFS:(98901004);DIR:INB;SFP:;SCL:1;SRVR:CY1NAM02HT159;H:COL004-MC4F46.hotmail.com;FPR:;SPF:None;LANG:en;EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:SN1NAM02HT242;H:CY4PR2001MB1847.namprd20.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id:
1c8bfd36-4ddd-4851-6237-08d4c9e6f65d
x-microsoft-antispam:
BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(23075)(8291501071);SRVR:CY1NAM02HT159;UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(421252002)(300000503095)(300135400095)(2017031320274)(201705091528075)(201702221075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:SN1NAM02HT242;
x-ms-traffictypediagnostic: CY1NAM02HT159:|SN1NAM02HT242:
x-exchange-antispam-report-test:
UriScan:(88407537951076)(148322886591682)(42944971172136)(236129657087228)(192374486261705)(31418570063057)(157321974039653)(48057245064654)(148574349560750)(81227570615382);UriScan:(88407537951076)(148322886591682)(236129657087228)(192374486261705)(31418570063057)(48057245064654)(148574349560750)(81227570615382)(167848164394848)(163839114692);
x-exchange-antispam-report-cfa-test:
BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444111536)(595095)(82015058);SRVR:CY1NAM02HT159;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1NAM02HT159;BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:SN1NAM02HT242;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN1NAM02HT242;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-originalarrivaltime: 13 Jul 2017 12:01:56.0226
(UTC)
x-ms-exchange-crosstenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
x-ms-exchange-crosstenant-fromentityheader: Internet
x-ms-exchange-transport-crosstenantheadersstamped: CY1NAM02HT159
x-ms-exchange-transport-endtoendlatency: 00:00:01.7113979
x-ms-exchange-processed-by-bccfoldering: 15.01.1240.000
Resent-From: <[REDACTED]>
x-microsoft-exchange-diagnostics-untrusted:
1;CY1NAM02HT159;7:l6kvKsqtmtS7u1GupATNSrS1E4L0YiVDUMqJhUm/OJ5KmR5QspuMKEorNpjK9oxaiG9GmazTaBF/COESR014o4P5DPxquY7Q/VY+xvaQKo2bZ1rtqPTvcA+iW4vaCcn1Mu8iSOZgLY03XQoJGYz+O7Remuqr6Xh64aji/DbGUHoDcyUbsQb86Cjnr6rUVQrUFZbOGf9Mzaj5QBXnT9h2Kj6Gne/lqgSDVyv6RwA/te50SN1Oq8S2UGmsmzW0rVGCtmuIAsmu2pswinsVutQ9bGMkCFLWyqXxvqvr/MU1XWyXZK7YIAQZG2LHkw34S8hwLRV20bReigf+bZrwiBsBY89gGaKZBzSSb/BaJQt9O9n342genjSrDA2NGxcBq/7RLK0lkkFo+9sOU2Y/wpkOU+fsyDYgdqTwR0bWJoMFmz+xSFlCaTTWbJtKIXv/z69ivDcHiwYIuvdT4b01qEC8i6VuoG2m1EagAODokUcS3QBWOiM7IV9BjVpeWbKS4blzJDO1LdCebSKKaiuTGUK1AtdKnEXmyVVpfqxmQEDC7kgotaxPOGFR8IHKFUWl7HlxEivS5ZgAnvvcZKv1bUDcWyfoOho1CiLaoNpx65grE66lh6OU6sJ1FViGsePYfWQ2zSVePZ0ixa608+UiMjr8wIugStYK7iWufAdCAN4eEb6KCiGujSFOKVW5+Y01KRiTD6srrTVs3UrKGHHwxuwuLPjuAgfzaAa00eZQ6CP2YvxecW4tSOS8nV5I3UTcoiCfDwdai2u3QkosYUYiHtspjDK3nuUOdMbbPMNGtFGxZ+w=
x-ms-exchange-transport-crosstenantheadersstripped:
SN1NAM02FT046.eop-nam02.prod.protection.outlook.com
x-forefront-prvs: 0367A50BB1
Content-Type: multipart/alternative;
boundary="_000_4c1d0cf4959586b47ef210e9cd34ffee5e0201707131201346fecbb_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2017 12:01:57.8433
(UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT242
Return-Path: ***@quantopian.com

[John Levine via dmarc-discuss]

Post by Jonathan Kamens via dmarc-discuss
Can we do anything to prevent messages such as this one from bouncing
when we turn on p=reject?

Probably not.

Perhaps you could back up and tell us what problem you expect to solve
by turning on p=reject. Unless you are a target of an unusual amount
of phishing or malicious forgery, p=reject often causes more problems
than it solves.

R's,
John
_______________________________________________
dmarc-discuss mailing list
dmarc-***@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[Randal Pinto via dmarc-discuss]

Jonathan,

This is a known issue with Microsoft:
https://blogs.msdn.microsoft.com/tzink/2016/05/19/why-does-my-email-from-facebook-that-i-forward-from-my-outlook-com-account-get-rejected/

and
https://blogs.msdn.microsoft.com/tzink/2017/06/22/an-update-on-the-
forwarding-email-problem-in-office-365/

If their example applies to your message, it is probably because
Kelly Elmstrom <***@quantopian.com> <***@quantopian.com>
is being "fixed" to:
"Kelly Elmstrom" <***@quantopian.com> <***@quantopian.com>
and that breaks DKIM.

You may want to try to change your marketing campaign to add the double
quotes on the name and see whether that fixes the problem. Long shot...
<https://blogs.msdn.microsoft.com/tzink/2017/06/22/an-update-on-the-forwarding-email-problem-in-office-365/>
ARC (arc-spec.org) is also been specified exactly to overcome these
scenarios. Google and AOL already implement it.

p=reject is the only real form of protection not only for impersonation
attacks but also to prevent mass spam senders from using your domain name
(the latter is more common than you think).

Best,
Randal


On 13 July 2017 at 17:49, John Levine via dmarc-discuss <

Post by John Levine via dmarc-discuss

Post by Jonathan Kamens via dmarc-discuss
Can we do anything to prevent messages such as this one from bouncing
when we turn on p=reject?

Probably not.
Perhaps you could back up and tell us what problem you expect to solve
by turning on p=reject. Unless you are a target of an unusual amount
of phishing or malicious forgery, p=reject often causes more problems
than it solves.
R's,
John
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well
terms (http://www.dmarc.org/note_well.html)

[Jonathan Kamens via dmarc-discuss]

Frankly, the primary problem I am trying to solve is that hackers in our
HackerOne bug-bounty program and random white-hat hackers on the
internet keep breathlessly reporting to us that it's a security problem
that we don't have DMARC configured on our domain and expecting us to be
overwhelmed with gratitude that they've revealed their amazing discovery
to us and in gratitude shower them with rose petals and bug-bounty cash.

I'm not an email newbie. When I started maintaining mail servers, I was
writing sendmail.cf files by hand because the m4 cf templates didn't
exist yet. I've submitted patches to both sendmail and postfix. I
maintain several open-source milters. My personal email has been hosted
on a mail server I maintain for 28 years, and my personal email domain
has both SPF and DKIM. In short, I have a pretty good idea about how all
this stuff hangs together.

I have always been skeptical about the value and design details of
DMARC. I am hoping that this is just because I misunderstand it, and,
indeed, I've learned a thing or two from the advice I've received on
this list and from the experience of trying to deploy it. But at the
same time, some of what I've learned seems to confirm my impression that
DMARC is unreliable because of problematic elements scattered throughout
its design and implementation.

So, what am I trying to accomplish, aside from the trivial goal of
making hackers stop emailing me?

Simply put, I want to make it more likely that legitimate emails from
our domain will be delivered, and more likely that forged emails
purporting to be from our domain will be rejected.

We do not have enough of a problem with forged emails that I am willing
to do anything that will cause legitimate emails that have been accepted
in the past to start being bounced because of DMARC. It is more
important to me for legitimate emails to get through than for forged
emails to be bounced.

Furthermore, we can't afford to use DMARC if that means actively
maintaining our email reputation on a near-daily basis. We're a small
company, and we have way bigger fish to fry. If it's not possible to
roll out DMARC for our domain without making a commitment to spending
time on a regular basis reviewing DMARC reports, either directly or
through something like dmarcian, then it's probably not feasible for us
to use DMARC.

Here's some of what I feel like I've learned so far:

* Reviewing DMARC aggregate reports by hand -- i.e., just loading the
XML files into a text editor and searching them for potential
problems -- on an ongoing basis is far too time-consuming to be
sustainable. Instead, you can skip getting the reports; or you can
file the reports in a separate folder and only look at them when
you're investigating a known delivery issue; or you can feed the
reports through a service like dmarcian and review them there.
* Not everybody who pays attention to DMARC records generates
aggregate reports. Not everybody who pays attention to DMARC records
generates failure reports. It's entirely possible that some
legitimate emails from us will be rejected due to DMARC failures
without my finding out that's happening until much later, if at all.
* There is no on-ramp for DMARC that will allow me to know with
certainty what the impact of DMARC will be before it starts causing
some legitimate emails to be bounced. Though the DMARC spec tries to
create such an on-ramp, the way email providers interpret DMARC in
real life is quirky and highly variable from provider to provider.
o One example of this is the fact that although one would think
that "p=none pct=100" and "p=reject pct=0" would have exactly
the same practical effect, in fact they behave differently at
some sites.
o Another example is, as Roland wrote, the fact that "you can't
reliably infer that a failure report received at p=none (or 0%
quarantine) will mean a reject at p=reject."
* There are currently several known issues with entirely legitimate
messages sent through major email providers being bounced due to
p=reject, most notably the Microsoft issue that Terry mentioned.

It feels to me like my unease about DMARC stems from the fact that the
folks who wrote the spec and the sites that are enforcing DMARC have a
markedly different philosophy than I do about email. This difference was
highlighted by a comment in Roland's email, when he asked "how much
collateral damage [I'm] willing to accept." This approach -- that some
"collateral damage" to legitimate email delivery is acceptable when
trying to stop forgeries -- was entirely foreign to how email was
thought about when I started working it, and it's still extraordinarily
difficult for me to come to grips with.

So, where do I go from here?

a) Give up on DMARC entirely, at least until things improve to the point
where the major providers are no longer suffering from issues such as
the Microsoft issue.

b) Set our DMARC record to "p=none; pct=0" and unset "rua" and "ruf".
But then if we start doing something different from email delivery at
some point in the future, e.g., we start using a new third-party service
provider that is sending emails on our behalf and forget to configure
SPF or DKIM properly for them, we won't know about it.

c) Like (b), but use an "rua" that sends the emails to somebody like
dmarcian that will process them for us in a way that makes them more
useful and less time-consuming.

I'm not really sure yet where I'm headed with this.

jik

Post by John Levine via dmarc-discuss

Post by Jonathan Kamens via dmarc-discuss
Can we do anything to prevent messages such as this one from bouncing
when we turn on p=reject?

Probably not.
Perhaps you could back up and tell us what problem you expect to solve
by turning on p=reject. Unless you are a target of an unusual amount
of phishing or malicious forgery, p=reject often causes more problems
than it solves.
R's,
John

[John R Levine via dmarc-discuss]

Post by Jonathan Kamens via dmarc-discuss
So, what am I trying to accomplish, aside from the trivial goal of
making hackers stop emailing me?

As we hardly need tell you, there's no cure for stupid. Perhaps a comment
in your DMARC record saying that bug reports will be met with ridicule,
and some procmail scripts to ridicule any bug reports that mention DMARC
would help.

Post by Jonathan Kamens via dmarc-discuss
It feels to me like my unease about DMARC stems from the fact that the
folks who wrote the spec and the sites that are enforcing DMARC have a
markedly different philosophy than I do about email.

DMARC was originally intended for places like Paypal that have severe
forgery problems and consciously are willing to lose some mail in return
for less forgery. (It probably helps that the only mail Paypal sends says
"something happened, log in to your account to see what it is.") Then AOL
and Yahoo used it to outsource the costs of having their user address
books stolen and things went downhill from there. Now as you've seen it's
the FUSSP of the month.

I use p=none and ask for reports, which I process automatically with some
little scripts that put the interesting bits in a mysql database at which
I very occasionally look. Sounds like that's right for you, too.

The scripts are here: https://www.taugh.com/rddmarc/

R's,
John
_______________________________________________
dmarc-discuss mailing list
dmarc-***@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[Jonathan Kamens via dmarc-discuss]

Post by Jonathan Kamens via dmarc-discuss
So, what am I trying to accomplish, aside from the trivial goal of
making hackers stop emailing me?

As we hardly need tell you, there's no cure for stupid.  Perhaps a
comment in your DMARC record saying that bug reports will be met with
ridicule, and some procmail scripts to ridicule any bug reports that
mention DMARC would help.

Oh, how I would love to do that, but alas, it would not be in my
employer's best interest for me to be anything but unfailingly polite to
the people reporting security issues to us, regardless of how much they
try my patience.

I use p=none and ask for reports, which I process automatically with
some little scripts that put the interesting bits in a mysql database
at which I very occasionally look.  Sounds like that's right for you,
too.
The scripts are here:  https://www.taugh.com/rddmarc/

Thanks for the pointer. There are actually a lot of open-source DMARC
tools out there. I uncovered a lot of them inadvertently when I was
actually trying to figure out why Github was generating emails claiming
to be from our domain that were failing DMARC... I searched for "github
dmarc" <https://www.google.com/search?q=github+dmarc> and uncovered a
whole bunch of interesting public repositories.

For the time being, I'm using the free DMARC aggregator provided by
Postmark <https://dmarc.postmarkapp.com/>, which has been sufficient to
uncover a number of issues, some of which we've already resolved and
others (including the mysterious Github emails I'm trying to figure out)
we're still working on.

  jik

[Dave Crocker via dmarc-discuss]

Post by Jonathan Kamens via dmarc-discuss
Oh, how I would love to do that, but alas, it would not be in my
employer's best interest for me to be anything but unfailingly polite to
the people reporting security issues to us, regardless of how much they
try my patience.

“Tact is the ability to tell someone to go to hell in such a way that
they look forward to the trip.”

― Winston S. Churchill


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc-discuss mailing list
dmarc-***@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.

[Roland Turner via dmarc-discuss]

my impression that DMARC is unreliable because of problematic elements
scattered throughout its design and implementation.

DMARC is only "unreliable" if you start with unrealistic expectations.
The idea that domain registrants get to tell receivers what to do with
email, or even to require them to provide feedback, is pretty obviously
absurd. DMARC permits domain registrants to request these things and -
to the extent the receivers are willing - to receive feedback.

Of necessity, DMARC reflects the email environment as it is, rather than
an idealised form of it. As in so many other contexts, once the lights
come on, the rough edges become visible.

That DMARC is being peddled by some as the current FUSSP is unfortunate,
but that doesn't invalidate DMARC, only the positions of those who are
doing this.

Simply put, I want to make it more likely that legitimate emails from
our domain will be delivered,

DMARC p=none helps indirectly by providing a means for you to discover
DNS/MTA issues under your control, and therefore to promptly fix them.
Obviously this requires automatic monitoring and alerting of feedback,
exactly because you aren't likely to read XML reports day in and day out
indefinitely.

and more likely that forged emails purporting to be from our domain
will be rejected.
We do not have enough of a problem with forged emails that I am
willing to do anything that will cause legitimate emails that have
been accepted in the past to start being bounced because of DMARC.

That's a really important decision. p=none is therefore the only option
that makes sense for you to use.

* Reviewing DMARC aggregate reports by hand -- i.e., just loading
the XML files into a text editor and searching them for potential
problems -- on an ongoing basis is far too time-consuming to be
sustainable. Instead, you can skip getting the reports; or you can
file the reports in a separate folder and only look at them when
you're investigating a known delivery issue; or you can feed the
reports through a service like dmarcian and review them there.

Most of the available value comes from automated monitoring over an
extended period but, yes, I also simply accumulate aggregate reports for
reactive diagnosis in some cases.

* Not everybody who pays attention to DMARC records generates
aggregate reports. Not everybody who pays attention to DMARC
records generates failure reports. It's entirely possible that
some legitimate emails from us will be rejected due to DMARC
failures without my finding out that's happening until much later,
if at all.

Yes. Most of these issues were apparent to me when I first saw DMARC
presented at MAAWG. I therefore asked, and the response was that some
feedback is better than no feedback and that some implementation of
proposed disposition was better than none. That has been the guiding
principle from the outset and, pretty clearly, is the only way this can
work. DMARC is not a piece of software that you install and run in a
closed system that you control, it's a series of requests to third
parties who have a range of higher and/or conflicting priorities.

The idea that DMARC is bad because it doesn't give perfect feedback or
perfect control rather misses the point.

* There is no on-ramp for DMARC that will allow me to know with
certainty what the impact of DMARC will be before it starts
causing some legitimate emails to be bounced. Though the DMARC
spec tries to create such an on-ramp, the way email providers
interpret DMARC in real life is quirky and highly variable from
provider to provider.

DMARC does not attempt to create on-ramp that gives you certainty. It
does do various things to ease transition, certainly. For contrast,
compare SPF -all (even if you're willing to field an instrumented DNS
server), DomainKeys o=-, and ADSP discardable. In each case, domain
registrants employing these mechanisms were essentially shooting
blindly, unless they were large enough to maintain (or pay for the use
of) seed boxes. DMARC's reporting mechanism profoundly changed that
situation, and is arguably the primary reason that it succeeded where
e.g. ADSP did not. (There were also some important differences in
development process that were relevant.)

o One example of this is the fact that although one would think
that "p=none pct=100" and "p=reject pct=0" would have exactly
the same practical effect, in fact they behave differently at
some sites.

I assume that you mean _p=quarantine; pct=0_; . _p=reject; pct=0;_ is
supposed to behave differently.

This is a neat hack that breaks the principle of pct=0, however it does
so in a way which benefits domain registrants, so is hardly a problem.
The great concern initially was that receivers would act in ways that
moved in the reverse direction.

o Another example is, as Roland wrote, the fact that "you can't
reliably infer that a failure report received at p=none (or 0%
quarantine) will mean a reject at p=reject."

Indeed, but this is not a critique of DMARC, it's an acknowledgement
that receivers make their own decisions.

* There are currently several known issues with entirely legitimate
messages sent through major email providers being bounced due to
p=reject, most notably the Microsoft issue that Terry mentioned.

Indeed. Again, not a DMARC problem; the email system contains many
species of weirdness like this. DMARC exposes them more clearly than
before, certainly.

It feels to me like my unease about DMARC stems from the fact that the
folks who wrote the spec and the sites that are enforcing DMARC have a
markedly different philosophy than I do about email. This difference
was highlighted by a comment in Roland's email, when he asked "how
much collateral damage [I'm] willing to accept." This approach -- that
some "collateral damage" to legitimate email delivery is acceptable
when trying to stop forgeries -- was entirely foreign to how email was
thought about when I started working it, and it's still
extraordinarily difficult for me to come to grips with.

I understand that. I would suggest that you're not alone in this, and
that a large part of the failure of the previous mechanisms was that the
IETF process couldn't get past this and so kept making bad decisions.
DMARC made progress by letting go of several sacred cows.

So, where do I go from here?
a) Give up on DMARC entirely, at least until things improve to the
point where the major providers are no longer suffering from issues
such as the Microsoft issue.

As John has suggested, mocking people who are reporting DMARC p!=none as
a vulnerability might be a more appropriate choice.

If you see no value in visibility into what's happening to your email
when it leaves your control then, sure, stop spending time on DMARC.

b) Set our DMARC record to "p=none; pct=0" and unset "rua" and "ruf".
But then if we start doing something different from email delivery at
some point in the future, e.g., we start using a new third-party
service provider that is sending emails on our behalf and forget to
configure SPF or DKIM properly for them, we won't know about it.
c) Like (b), but use an "rua" that sends the emails to somebody like
dmarcian that will process them for us in a way that makes them more
useful and less time-consuming.

This is pretty much a foregone conclusion. Monitoring requires software.
You really don't want to do it by hand.

- Roland

[Terry Zink via dmarc-discuss]

This would be due to mailbox forwarding, which currently breaks DKIM and therefore DMARC.

Here’s the latest on that: https://blogs.msdn.microsoft.com/tzink/2017/06/22/an-update-on-the-forwarding-email-problem-in-office-365/

--Terry

From: dmarc-discuss [mailto:dmarc-discuss-***@dmarc.org] On Behalf Of Jonathan Kamens via dmarc-discuss
Sent: Thursday, July 13, 2017 6:49 AM
To: dmarc-***@dmarc.org
Subject: [dmarc-discuss] Anything to be done about DMARC failures caused by internal Microsoft forwards?


I finally got a couple DMARC failure reports this morning -- the first two failure reports I've received -- and they're false DMARC failures for legitimate emails that apparently will be bounced incorrectly if we turn on p=reject.

In both cases, we were emailing someone (through MailChimp) with a live.com email address. Our SPF and DKIM both passed when outlook.com (which handles email for live.com) received the message. Then, however, the message was forwarded from outlook.com to hotmail.com, and hotmail.com reported it as a DMARC failure.

I have no way of knowing whether this is because the user has both live.com and hotmail.com accounts and configured the former to forward to the latter, or whether in fact all live.com emails are forwarded internally by Microsoft to hotmail.com.

I've appended the bounce report and message headers from one of the bounced messages below.

Can we do anything to prevent messages such as this one from bouncing when we turn on p=reject?

Thanks,

Jonathan Kamens

Here's the bounce report:

Feedback-Type: auth-failure
User-Agent: XMR/2.2
Version: 1.0
Original-Mail-From: <***@quantopian.com><mailto:***@quantopian.com>
Arrival-Date: Thu, 13 Jul 2017 05:02:03 -0700
Message-ID: <***@mail220.atl61.mcsv.net><mailto:***@mail220.atl61.mcsv.net>
Authentication-Results: hotmail.com; spf=fail (sender IP is 40.92.4.105; identity alignment result is pass and alignment mode is relaxed) smtp.mailfrom=***@quantopian.com<mailto:smtp.mailfrom=***@quantopian.com>; dkim=fail (identity alignment result is pass and alignment mode is relaxed) header.d=quantopian.com; x-hmca=fail header.id=***@quantopian.com<mailto:header.id=***@quantopian.com>
Source-IP: 40.92.4.105
Auth-Failure: spf
Reported-Domain: quantopian.com
DKIM-Domain: quantopian.com
DKIM-Identity: ***@quantopian.com<mailto:***@quantopian.com>
DKIM-Selector: k1

Here are the message headers. I'm sure most of them are irrelevant, but I've left everything because I'm not 100% what might and might not be useful:

Authentication-Results: hotmail.com; spf=fail (sender IP is 40.92.4.105; identity alignment result is pass and alignment mode is relaxed) smtp.mailfrom=***@quantopian.com<mailto:smtp.mailfrom=***@quantopian.com>; dkim=fail (identity alignment result is pass and alignment mode is relaxed) header.d=quantopian.com; x-hmca=fail header.id=***@quantopian.com<mailto:header.id=***@quantopian.com>
X-Envelope-Sender: ***@quantopian.com<mailto:***@quantopian.com>
X-SID-PRA: ***@quantopian.com<mailto:***@quantopian.com>
X-AUTH-Result: FAIL
X-SID-Result: FAIL
Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([40.92.4.105]) by SNT004-MC6F1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23143);
Thu, 13 Jul 2017 05:02:03 -0700
Received: from SN1NAM02FT046.eop-nam02.prod.protection.outlook.com
(10.152.72.59) by SN1NAM02HT242.eop-nam02.prod.protection.outlook.com
(10.152.73.41) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1220.9; Thu, 13
Jul 2017 12:01:57 +0000
Received: from CY4PR2001MB1847.namprd20.prod.outlook.com (10.152.72.54) by
SN1NAM02FT046.mail.protection.outlook.com (10.152.72.191) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1240.9 via Frontend Transport; Thu, 13 Jul 2017 12:01:57 +0000
Received: from CY4PR2001MB1847.namprd20.prod.outlook.com ([127.0.0.1]) by
CY4PR2001MB1847.namprd20.prod.outlook.com ([10.171.214.15]) with Microsoft
SMTP Server id 15.01.1240.020; Thu, 13 Jul 2017 12:01:57 +0000
From: Kelly Elmstrom <***@quantopian.com><mailto:***@quantopian.com>
To: "REDACTED" <***@outlook.com><mailto:***@outlook.com>
Subject: Don't Miss the Quantopian Events in Seattle this Week
Thread-Topic: Don't Miss the Quantopian Events in Seattle this Week
Date: Thu, 13 Jul 2017 12:01:51 +0000
Message-ID: <***@mail220.atl61.mcsv.net><mailto:***@mail220.atl61.mcsv.net>
List-Unsubscribe: <http://quantopian.us5.list-manage.com/unsubscribe?u=4c1d0cf4959586b47ef210e9c&id=7cca55778a&e=d34ffee5e0&c=6fecbb115c><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fquantopian.us5.list-manage.com%2Funsubscribe%3Fu%3D4c1d0cf4959586b47ef210e9c%26id%3D7cca55778a%26e%3Dd34ffee5e0%26c%3D6fecbb115c&data=02%7C01%7Ctzink%40microsoft.com%7Ca84ac55eef0e46cd05dd08d4c9f6dea5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636355509518454164&sdata=2Vnhd4Em1BrEkHRJzt854mOMktDmR2H%2BSe8iqCDKzjo%3D&reserved=0>,
<mailto:unsubscribe-mc.us5_4c1d0cf4959586b47ef210e9c.6fecbb115c-***@mailin1.us2.mcsv.net?subject=unsubscribe><mailto:unsubscribe-mc.us5_4c1d0cf4959586b47ef210e9c.6fecbb115c-***@mailin1.us2.mcsv.net?subject=unsubscribe>
Reply-To: Kelly Elmstrom <***@quantopian.com><mailto:***@quantopian.com>
X-MS-Has-Attach:
X-MS-Exchange-Inbox-Rules-Loop: [REDACTED]
X-MS-TNEF-Correlator:
authentication-results: spf=pass (sender IP is 205.201.135.220)
smtp.mailfrom=mail220.atl61.mcsv.net; live.com; dkim=pass (signature was
verified) header.d=quantopian.com;live.com; dmarc=pass action=none
header.from=quantopian.com;
received-spf: Pass (protection.outlook.com: domain of mail220.atl61.mcsv.net
designates 205.201.135.220 as permitted sender)
receiver=protection.outlook.com; client-ip=205.201.135.220; helo=
mail220.atl61.mcsv.net;
x-incomingtopheadermarker: OriginalChecksum:BA85BFE3DA5687159ECBDF6BCC7014F3FDC727FEBF2BD8223B58DB3FBCD4ECAD;UpperCasedChecksum:CB294777FAAF9F767FCD2A1D612E88117F017CC9C14DD8F25C933E42F8F72DC2;SizeAsReceived:2369;Count:24
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; d=quantopian.com;
h=Subject:From:Reply-To:To:Date:Message-ID:List-ID:List-Unsubscribe:
Content-Type:MIME-Version; i=***@quantopian.com<mailto:i=***@quantopian.com>;
bh=fDDC6i/MTFX2fZe+gjuYKbYoZZS/MeyDpfQSfNPCg+c=;
b=sYYINiy3JzTRoF4g2sSCLTnycEJUVPJvesDiM5Nk/F/X2gLFVJeO75MsPmuapP1oT1n6xvNFesHr
7r1N61LXtWkagZoH4cT70aP8uShLi6LAAPG9tBiRat5vah40x271Wjb4rlE8Zyfiy0gbNd3F/Tkc
OcoSjjxxiWSotHhdh9g=
x-mailer: MailChimp Mailer - **CID6fecbb115cd34ffee5e0**
x-campaign: mailchimp4c1d0cf4959586b47ef210e9c.6fecbb115c
x-campaignid: mailchimp4c1d0cf4959586b47ef210e9c.6fecbb115c
x-report-abuse: Please report abuse for this campaign here:
http://www.mailchimp.com/abuse/abuse.phtml?u=4c1d0cf4959586b47ef210e9c&id=6fecbb115c&e=d34ffee5e0<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mailchimp.com%2Fabuse%2Fabuse.phtml%3Fu%3D4c1d0cf4959586b47ef210e9c%26id%3D6fecbb115c%26e%3Dd34ffee5e0&data=02%7C01%7Ctzink%40microsoft.com%7Ca84ac55eef0e46cd05dd08d4c9f6dea5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636355509518454164&sdata=rCWjQtMiydReZY3On3mdatiRpxGxjBetGKg9f0AxsBQ%3D&reserved=0>
x-mc-user: 4c1d0cf4959586b47ef210e9c
feedback-id: 11246039:11246039.669585:us5:mc
list-id: 4c1d0cf4959586b47ef210e9cmc list
<4c1d0cf4959586b47ef210e9c.51129.list-id.mcsv.net>
x-accounttype: pd
list-unsubscribe-post: List-Unsubscribe=One-Click
x-mcda: FALSE
x-originalarrivaltime: 13 Jul 2017 12:01:55.0746 (UTC)
FILETIME=[D29CD020:01D2FBCF]
x-incomingheadercount: 74
x-eopattributedmessage: 1
x-eoptenantattributedmessage: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa:0
cmm-sender-ip: 205.201.135.220
cmm-sending-ip: 205.201.135.220
cmm-authentication-results: hotmail.com; spf=pass (sender IP is
205.201.135.220; identity alignment result is fail and alignment mode is
relaxed)
smtp.mailfrom=bounce-mc.us5_11246039.669585-[REDACTED]@mail220.atl61.mcsv.net<mailto:REDACTED]@mail220.atl61.mcsv.net>;
dkim=pass (identity alignment result is pass and alignment mode is relaxed)
header.d=quantopian.com; x-hmca=pass header.id=***@quantopian.com<mailto:header.id=***@quantopian.com>
cmm-x-sid-pra: ***@quantopian.com<mailto:***@quantopian.com>
cmm-x-auth-result: PASS
cmm-x-sid-result: PASS
cmm-x-message-status: n:n
cmm-x-message-delivery: Vj0xLjE7dXM9MDtsPTE7YT0xO0Q9MTtHRD0xO1NDTD0w
cmm-x-message-info: NhFq/7gR1vQgiyfVu7hHjX7cEIYUGy9ouVv27+kUvOh+yT9R6U8S694jjriTSk6ax/qvBdv+DTZmeVqcMniXZ3Y9aVKmfyQuSdonHbwSn1bdiAFvbAgTAZsA2rLNg5/1ItACMdFg3tujsw/TO2XSDArnCj8YxbXIfN/ynuETGNw96wF4BVIGxT9NbjbN1urGJncvJFgHXO2p4RsOxdCq3uPjhKnJIOatLy0Sb8QC515gdGL0iskb3yq6YCIav7/p
x-microsoft-exchange-diagnostics: 1;SN1NAM02HT242;7:G4L9jHxiJKN4Cf8ouwQX/MT6S88IVIqK+T0ClcAezjD3UKZl7SwqfOWfqk89MABbuUQubb4163Qc0t/zDHCiCpU2SYAZq4FFhyJ3Eh0J/pcg6PUWiOpBwCDKsHPV2osLohgq3hX7kFKV2bJP41RXTmQKUChtq5RCA9xEJHr/IOR94bNfFf6vQMwcoFNORDqYyDBPGZwZKvzOh323UbRlNEPrW2oyNjkF//IMrVeD0kraM3ajyZzA9u/CxmjeBBTafcxCwmEr3halV1+q9oOklhBWvIMRsuh8ZjALwZkh4Ns8YRUMiZsTPeXgXDRP0Pt+JvY6vpOHoNd67KRDZcog/O+WE7vtuSfGd0rOmZH2p0uBfxsIYYetB8kChqrknwV2IgDLW0OC1gQ46d9F5IEfYg/QWq8Q2uZWIwKxNT7iYhYIiHhcbUo7R6OYhOwpnSz8sMBpF02p6ZI/zqhxKog6OX32m2xXBh9kRvLBXqKC7Y7dmofwt+iV32zgD6jyWO5MxyEjZyMBypbNftEur7K3H1NkGtPofYAaHKyvLBZ8eic6IiQbrD3Z2gx9AgLr08u8d1XYCCDMbuPTWpdLAYG4dxoXC/kLcJ9ZeyCr1dAUVMzzu4kJorolCFxXLLcEZEc7JxibW0+KlNkY7Ccb3XreQxq0+HXHz2R8moLjT9QYgb3tK+qLhmv3tZ2jx/JvOQecCs5vSJzCIciN2hsi5yxU82K2LBuJo9gfgshfI/Sl1K21MYSogngUjq4ZvY1sJu+HfayyzKlu0IScQMJEafsjbQ==
x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(98901004);DIR:INB;SFP:;SCL:1;SRVR:CY1NAM02HT159;H:COL004-MC4F46.hotmail.com;FPR:;SPF:None;LANG:en;EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:SN1NAM02HT242;H:CY4PR2001MB1847.namprd20.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1c8bfd36-4ddd-4851-6237-08d4c9e6f65d
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(23075)(8291501071);SRVR:CY1NAM02HT159;UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(421252002)(300000503095)(300135400095)(2017031320274)(201705091528075)(201702221075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:SN1NAM02HT242;
x-ms-traffictypediagnostic: CY1NAM02HT159:|SN1NAM02HT242:
x-exchange-antispam-report-test: UriScan:(88407537951076)(148322886591682)(42944971172136)(236129657087228)(192374486261705)(31418570063057)(157321974039653)(48057245064654)(148574349560750)(81227570615382);UriScan:(88407537951076)(148322886591682)(236129657087228)(192374486261705)(31418570063057)(48057245064654)(148574349560750)(81227570615382)(167848164394848)(163839114692);
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444111536)(595095)(82015058);SRVR:CY1NAM02HT159;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1NAM02HT159;BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:SN1NAM02HT242;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN1NAM02HT242;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-originalarrivaltime: 13 Jul 2017 12:01:56.0226 (UTC)
x-ms-exchange-crosstenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
x-ms-exchange-crosstenant-fromentityheader: Internet
x-ms-exchange-transport-crosstenantheadersstamped: CY1NAM02HT159
x-ms-exchange-transport-endtoendlatency: 00:00:01.7113979
x-ms-exchange-processed-by-bccfoldering: 15.01.1240.000
Resent-From: <[REDACTED]>
x-microsoft-exchange-diagnostics-untrusted: 1;CY1NAM02HT159;7:l6kvKsqtmtS7u1GupATNSrS1E4L0YiVDUMqJhUm/OJ5KmR5QspuMKEorNpjK9oxaiG9GmazTaBF/COESR014o4P5DPxquY7Q/VY+xvaQKo2bZ1rtqPTvcA+iW4vaCcn1Mu8iSOZgLY03XQoJGYz+O7Remuqr6Xh64aji/DbGUHoDcyUbsQb86Cjnr6rUVQrUFZbOGf9Mzaj5QBXnT9h2Kj6Gne/lqgSDVyv6RwA/te50SN1Oq8S2UGmsmzW0rVGCtmuIAsmu2pswinsVutQ9bGMkCFLWyqXxvqvr/MU1XWyXZK7YIAQZG2LHkw34S8hwLRV20bReigf+bZrwiBsBY89gGaKZBzSSb/BaJQt9O9n342genjSrDA2NGxcBq/7RLK0lkkFo+9sOU2Y/wpkOU+fsyDYgdqTwR0bWJoMFmz+xSFlCaTTWbJtKIXv/z69ivDcHiwYIuvdT4b01qEC8i6VuoG2m1EagAODokUcS3QBWOiM7IV9BjVpeWbKS4blzJDO1LdCebSKKaiuTGUK1AtdKnEXmyVVpfqxmQEDC7kgotaxPOGFR8IHKFUWl7HlxEivS5ZgAnvvcZKv1bUDcWyfoOho1CiLaoNpx65grE66lh6OU6sJ1FViGsePYfWQ2zSVePZ0ixa608+UiMjr8wIugStYK7iWufAdCAN4eEb6KCiGujSFOKVW5+Y01KRiTD6srrTVs3UrKGHHwxuwuLPjuAgfzaAa00eZQ6CP2YvxecW4tSOS8nV5I3UTcoiCfDwdai2u3QkosYUYiHtspjDK3nuUOdMbbPMNGtFGxZ+w=
x-ms-exchange-transport-crosstenantheadersstripped: SN1NAM02FT046.eop-nam02.prod.protection.outlook.com
x-forefront-prvs: 0367A50BB1
Content-Type: multipart/alternative;
boundary="_000_4c1d0cf4959586b47ef210e9cd34ffee5e0201707131201346fecbb_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2017 12:01:57.8433
(UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT242
Return-Path: ***@quantopian.com<mailto:***@quantopian.com>

[Roland Turner via dmarc-discuss]

Jonathan,

Various things:

* A DMARC failure is not an accusation of wrong-doing, it's just a
report that an authentication mechanism failed. Consequently, this
isn't a false DMARC report; it's a true DMARC report of an
authentication failure arising from changes made during forwarding.
* You can't reliably infer that a failure report received at p=none
(or 0% quarantine) will mean a reject at p=reject. It is likely, but
not certain. Receivers make their own decisions about what to do
with incoming email, including about whether to override DMARC
results in either direction.
* A failure report (DMARC) and a bounce report (SMTP) are two
different things. This is a failure report.

On how to fix this; the answer depends in part upon the type of email
that you're sending, how determined your recipients are to receive it,
and how much damage you are currently suffering. For example, in
PayPal's case, the damage was serious enough that it was reasonable to
require that all customers each provide an actual mailbox address,
rather than forward from an old address or use a forward-only domain.

Per John's comments, you've not yet spelled out what problem you're
trying to solve and - therefore - how much collateral damage you're
willing to accept.

- Roland


------------------------------------------------------------------------

Post by Jonathan Kamens via dmarc-discuss
I finally got a couple DMARC failure reports this morning -- the first
two failure reports I've received -- and they're false DMARC failures
for legitimate emails that apparently will be bounced incorrectly if
we turn on p=reject.
In both cases, we were emailing someone (through MailChimp) with a
live.com email address. Our SPF and DKIM both passed when outlook.com
(which handles email for live.com) received the message. Then,
however, the message was forwarded from outlook.com to hotmail.com,
and hotmail.com reported it as a DMARC failure.
I have no way of knowing whether this is because the user has both
live.com and hotmail.com accounts and configured the former to forward
to the latter, or whether in fact all live.com emails are forwarded
internally by Microsoft to hotmail.com.
I've appended the bounce report and message headers from one of the
bounced messages below.
Can we do anything to prevent messages such as this one from bouncing
when we turn on p=reject?
Thanks,
Jonathan Kamens
Feedback-Type: auth-failure
User-Agent: XMR/2.2
Version: 1.0
Arrival-Date: Thu, 13 Jul 2017 05:02:03 -0700
Authentication-Results: hotmail.com; spf=fail (sender IP is
40.92.4.105; identity alignment result is pass and alignment mode is
alignment result is pass and alignment mode is relaxed)
Source-IP: 40.92.4.105
Auth-Failure: spf
Reported-Domain: quantopian.com
DKIM-Domain: quantopian.com
DKIM-Selector: k1
Here are the message headers. I'm sure most of them are irrelevant,
but I've left everything because I'm not 100% what might and might not
Authentication-Results: hotmail.com; spf=fail (sender IP is
40.92.4.105; identity alignment result is pass and alignment mode is
alignment result is pass and alignment mode is relaxed)
X-AUTH-Result: FAIL
X-SID-Result: FAIL
Received: from NAM02-CY1-obe.outbound.protection.outlook.com
([40.92.4.105]) by SNT004-MC6F1.hotmail.com over TLS secured channel
with Microsoft SMTPSVC(7.5.7601.23143);
Thu, 13 Jul 2017 05:02:03 -0700
Received: from SN1NAM02FT046.eop-nam02.prod.protection.outlook.com
(10.152.72.59) by SN1NAM02HT242.eop-nam02.prod.protection.outlook.com
(10.152.73.41) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1220.9; Thu, 13
Jul 2017 12:01:57 +0000
Received: from CY4PR2001MB1847.namprd20.prod.outlook.com (10.152.72.54) by
SN1NAM02FT046.mail.protection.outlook.com (10.152.72.191) with
Microsoft SMTP
Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1240.9 via Frontend Transport; Thu, 13 Jul 2017 12:01:57 +0000
Received: from CY4PR2001MB1847.namprd20.prod.outlook.com ([127.0.0.1]) by
CY4PR2001MB1847.namprd20.prod.outlook.com ([10.171.214.15]) with Microsoft
SMTP Server id 15.01.1240.020; Thu, 13 Jul 2017 12:01:57 +0000
Subject: Don't Miss the Quantopian Events in Seattle this Week
Thread-Topic: Don't Miss the Quantopian Events in Seattle this Week
Date: Thu, 13 Jul 2017 12:01:51 +0000
<http://quantopian.us5.list-manage.com/unsubscribe?u=4c1d0cf4959586b47ef210e9c&id=7cca55778a&e=d34ffee5e0&c=6fecbb115c>,
X-MS-Exchange-Inbox-Rules-Loop: [REDACTED]
authentication-results: spf=pass (sender IP is 205.201.135.220)
smtp.mailfrom=mail220.atl61.mcsv.net; live.com; dkim=pass (signature was
verified) header.d=quantopian.com;live.com; dmarc=pass action=none
header.from=quantopian.com;
received-spf: Pass (protection.outlook.com: domain of
mail220.atl61.mcsv.net
designates 205.201.135.220 as permitted sender)
receiver=protection.outlook.com; client-ip=205.201.135.220; helo=
mail220.atl61.mcsv.net;
OriginalChecksum:BA85BFE3DA5687159ECBDF6BCC7014F3FDC727FEBF2BD8223B58DB3FBCD4ECAD;UpperCasedChecksum:CB294777FAAF9F767FCD2A1D612E88117F017CC9C14DD8F25C933E42F8F72DC2;SizeAsReceived:2369;Count:24
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1;
d=quantopian.com;
bh=fDDC6i/MTFX2fZe+gjuYKbYoZZS/MeyDpfQSfNPCg+c=;
b=sYYINiy3JzTRoF4g2sSCLTnycEJUVPJvesDiM5Nk/F/X2gLFVJeO75MsPmuapP1oT1n6xvNFesHr
7r1N61LXtWkagZoH4cT70aP8uShLi6LAAPG9tBiRat5vah40x271Wjb4rlE8Zyfiy0gbNd3F/Tkc
OcoSjjxxiWSotHhdh9g=
x-mailer: MailChimp Mailer - **CID6fecbb115cd34ffee5e0**
x-campaign: mailchimp4c1d0cf4959586b47ef210e9c.6fecbb115c
x-campaignid: mailchimp4c1d0cf4959586b47ef210e9c.6fecbb115c
http://www.mailchimp.com/abuse/abuse.phtml?u=4c1d0cf4959586b47ef210e9c&id=6fecbb115c&e=d34ffee5e0
x-mc-user: 4c1d0cf4959586b47ef210e9c
feedback-id: 11246039:11246039.669585:us5:mc
list-id: 4c1d0cf4959586b47ef210e9cmc list
<4c1d0cf4959586b47ef210e9c.51129.list-id.mcsv.net>
x-accounttype: pd
list-unsubscribe-post: List-Unsubscribe=One-Click
x-mcda: FALSE
x-originalarrivaltime: 13 Jul 2017 12:01:55.0746 (UTC)
FILETIME=[D29CD020:01D2FBCF]
x-incomingheadercount: 74
x-eopattributedmessage: 1
x-eoptenantattributedmessage: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa:0
cmm-sender-ip: 205.201.135.220
cmm-sending-ip: 205.201.135.220
cmm-authentication-results: hotmail.com; spf=pass (sender IP is
205.201.135.220; identity alignment result is fail and alignment mode is
relaxed)
dkim=pass (identity alignment result is pass and alignment mode is relaxed)
cmm-x-auth-result: PASS
cmm-x-sid-result: PASS
cmm-x-message-status: n:n
cmm-x-message-delivery: Vj0xLjE7dXM9MDtsPTE7YT0xO0Q9MTtHRD0xO1NDTD0w
NhFq/7gR1vQgiyfVu7hHjX7cEIYUGy9ouVv27+kUvOh+yT9R6U8S694jjriTSk6ax/qvBdv+DTZmeVqcMniXZ3Y9aVKmfyQuSdonHbwSn1bdiAFvbAgTAZsA2rLNg5/1ItACMdFg3tujsw/TO2XSDArnCj8YxbXIfN/ynuETGNw96wF4BVIGxT9NbjbN1urGJncvJFgHXO2p4RsOxdCq3uPjhKnJIOatLy0Sb8QC515gdGL0iskb3yq6YCIav7/p
1;SN1NAM02HT242;7:G4L9jHxiJKN4Cf8ouwQX/MT6S88IVIqK+T0ClcAezjD3UKZl7SwqfOWfqk89MABbuUQubb4163Qc0t/zDHCiCpU2SYAZq4FFhyJ3Eh0J/pcg6PUWiOpBwCDKsHPV2osLohgq3hX7kFKV2bJP41RXTmQKUChtq5RCA9xEJHr/IOR94bNfFf6vQMwcoFNORDqYyDBPGZwZKvzOh323UbRlNEPrW2oyNjkF//IMrVeD0kraM3ajyZzA9u/CxmjeBBTafcxCwmEr3halV1+q9oOklhBWvIMRsuh8ZjALwZkh4Ns8YRUMiZsTPeXgXDRP0Pt+JvY6vpOHoNd67KRDZcog/O+WE7vtuSfGd0rOmZH2p0uBfxsIYYetB8kChqrknwV2IgDLW0OC1gQ46d9F5IEfYg/QWq8Q2uZWIwKxNT7iYhYIiHhcbUo7R6OYhOwpnSz8sMBpF02p6ZI/zqhxKog6OX32m2xXBh9kRvLBXqKC7Y7dmofwt+iV32zgD6jyWO5MxyEjZyMBypbNftEur7K3H1NkGtPofYAaHKyvLBZ8eic6IiQbrD3Z2gx9AgLr08u8d1XYCCDMbuPTWpdLAYG4dxoXC/kLcJ9ZeyCr1dAUVMzzu4kJorolCFxXLLcEZEc7JxibW0+KlNkY7Ccb3XreQxq0+HXHz2R8moLjT9QYgb3tK+qLhmv3tZ2jx/JvOQecCs5vSJzCIciN2hsi5yxU82K2LBuJo9gfgshfI/Sl1K21MYSogngUjq4ZvY1sJu+HfayyzKlu0IScQMJEafsjbQ==
EFV:NLI;SFV:NSPM;SFS:(98901004);DIR:INB;SFP:;SCL:1;SRVR:CY1NAM02HT159;H:COL004-MC4F46.hotmail.com;FPR:;SPF:None;LANG:en;EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:SN1NAM02HT242;H:CY4PR2001MB1847.namprd20.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-publictraffictype: Email
1c8bfd36-4ddd-4851-6237-08d4c9e6f65d
BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(23075)(8291501071);SRVR:CY1NAM02HT159;UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(421252002)(300000503095)(300135400095)(2017031320274)(201705091528075)(201702221075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:SN1NAM02HT242;
UriScan:(88407537951076)(148322886591682)(42944971172136)(236129657087228)(192374486261705)(31418570063057)(157321974039653)(48057245064654)(148574349560750)(81227570615382);UriScan:(88407537951076)(148322886591682)(236129657087228)(192374486261705)(31418570063057)(48057245064654)(148574349560750)(81227570615382)(167848164394848)(163839114692);
BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444111536)(595095)(82015058);SRVR:CY1NAM02HT159;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1NAM02HT159;BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:SN1NAM02HT242;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN1NAM02HT242;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-originalarrivaltime: 13 Jul 2017
12:01:56.0226 (UTC)
x-ms-exchange-crosstenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
x-ms-exchange-crosstenant-fromentityheader: Internet
x-ms-exchange-transport-crosstenantheadersstamped: CY1NAM02HT159
x-ms-exchange-transport-endtoendlatency: 00:00:01.7113979
x-ms-exchange-processed-by-bccfoldering: 15.01.1240.000
Resent-From: <[REDACTED]>
1;CY1NAM02HT159;7:l6kvKsqtmtS7u1GupATNSrS1E4L0YiVDUMqJhUm/OJ5KmR5QspuMKEorNpjK9oxaiG9GmazTaBF/COESR014o4P5DPxquY7Q/VY+xvaQKo2bZ1rtqPTvcA+iW4vaCcn1Mu8iSOZgLY03XQoJGYz+O7Remuqr6Xh64aji/DbGUHoDcyUbsQb86Cjnr6rUVQrUFZbOGf9Mzaj5QBXnT9h2Kj6Gne/lqgSDVyv6RwA/te50SN1Oq8S2UGmsmzW0rVGCtmuIAsmu2pswinsVutQ9bGMkCFLWyqXxvqvr/MU1XWyXZK7YIAQZG2LHkw34S8hwLRV20bReigf+bZrwiBsBY89gGaKZBzSSb/BaJQt9O9n342genjSrDA2NGxcBq/7RLK0lkkFo+9sOU2Y/wpkOU+fsyDYgdqTwR0bWJoMFmz+xSFlCaTTWbJtKIXv/z69ivDcHiwYIuvdT4b01qEC8i6VuoG2m1EagAODokUcS3QBWOiM7IV9BjVpeWbKS4blzJDO1LdCebSKKaiuTGUK1AtdKnEXmyVVpfqxmQEDC7kgotaxPOGFR8IHKFUWl7HlxEivS5ZgAnvvcZKv1bUDcWyfoOho1CiLaoNpx65grE66lh6OU6sJ1FViGsePYfWQ2zSVePZ0ixa608+UiMjr8wIugStYK7iWufAdCAN4eEb6KCiGujSFOKVW5+Y01KRiTD6srrTVs3UrKGHHwxuwuLPjuAgfzaAa00eZQ6CP2YvxecW4tSOS8nV5I3UTcoiCfDwdai2u3QkosYUYiHtspjDK3nuUOdMbbPMNGtFGxZ+w=
SN1NAM02FT046.eop-nam02.prod.protection.outlook.com
x-forefront-prvs: 0367A50BB1
Content-Type: multipart/alternative;
boundary="_000_4c1d0cf4959586b47ef210e9cd34ffee5e0201707131201346fecbb_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2017 12:01:57.8433
(UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT242
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)