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

2017-07-16 Thread Roland Turner via dmarc-discuss 

On 16/07/17 09:07, Jonathan Kamens via dmarc-discuss wrote:

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. 


This remains available, although as you've noticed it comes at a cost:

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

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

2017-07-16 Thread John R Levine 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.



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-discuss@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)

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

2017-07-13 Thread John Levine via dmarc-discuss 
In article  you write:
>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-discuss@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)

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

2017-07-13 Thread 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: 
Arrival-Date: Thu, 13 Jul 2017 05:02:03 -0700
Message-ID:
<4c1d0cf4959586b47ef210e9c.d34ffee5e0.20170713120134.6fecbb115c.5f4c8...@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=worksh...@quantopian.com; dkim=fail (identity alignment
result is pass and alignment mode is relaxed) header.d=quantopian.com;
x-hmca=fail header.id=worksh...@quantopian.com
Source-IP: 40.92.4.105
Auth-Failure: spf
Reported-Domain: quantopian.com
DKIM-Domain: quantopian.com
DKIM-Identity: worksh...@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=worksh...@quantopian.com; dkim=fail (identity alignment
result is pass and alignment mode is relaxed) header.d=quantopian.com;
x-hmca=fail header.id=worksh...@quantopian.com
X-Envelope-Sender: worksh...@quantopian.com
X-SID-PRA: worksh...@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 +
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 +
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 +
From: Kelly Elmstrom 
To: "REDACTED" 
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 +
Message-ID:
<4c1d0cf4959586b47ef210e9c.d34ffee5e0.20170713120134.6fecbb115c.5f4c8...@mail220.atl61.mcsv.net>
List-Unsubscribe:
,
 

Reply-To: Kelly Elmstrom 
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: