Re: [dmarc-discuss] Use of in DMARC aggregate reports

2021-12-20 Thread Jonathan Kamens via dmarc-discuss 
It's not yet fixed in OpenDMARC, unfortunately. I've reported it again
into Github at https://github.com/trusteddomainproject/OpenDMARC/issues/199.

On 12/20/21 08:30, Juri Haberland via dmarc-discuss wrote:
> On 02.12.21 13:34, Maarten Oelering via dmarc-discuss wrote:
>> Hi list members,
>>
>> We see many aggregate reports where  is a 
>> subdomain which does not publish a DMARC record. The DMARC record is on the 
>> organisation domain.
>> It’s so widespread it looks like some DMARC reporting software is broken. In 
>> one of the reports I saw "X-Mailer: opendmarc-reports v1.3.2".
> Yes, see https://sourceforge.net/p/opendmarc/tickets/207/
> The development has silently moved to Github, maybe it is fixed now...
>
>> Do others notice this as well? And how do you treat these reports, drop them 
>> or fix them?
> Just accepting as-is seems the best way IMHO.
>
>
> Regards,
>   Juri
> ___
> 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 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] Correct counting of DNS lookups for SPF record containing MX mechanism

2021-07-07 Thread Jonathan Kamens via dmarc-discuss 

On 7/7/21 2:11 PM, Alessandro Vesely via dmarc-discuss wrote:

On Wed 07/Jul/2021 15:19:35 +0200 Roland Turner via dmarc-discuss wrote:
A mailbox provider is only one of the service providers that an 
organisation might contract to send email on its behalf. Other common 
examples include:


  * Marketing automation (list management, sending mailouts, analytics)
  * CRMs, where sellers use the CRM itself to send messages to their 
customers

  * Subscription management systems that send expiry reminders
  * Helpdesk systems that send responses to user requests

There are dozens or hundreds of less common examples.
I see.  I note that the examples you mention, except some kind of 
marketing, need to receive mail, besides sending it.  Indeed, being 
bidirectional is a peculiar email characteristics.  So, if a service 
can be integrated with a mail system, then it should be able to use 
its incoming as well as outgoing servers.  Otherwise, it deserves 
using its own subdomain.


Companies do not want to use subdomains in the sender addresses of any 
of the types of email listed above. They want to be able to use 
addresses in their domain, because that's what looks natural and correct 
to customers. Subdomains confuse customers, and companies do not want to 
confuse their customers.


Furthermore, the systems enumerated above do not typically use the 
domain's corporate outgoing servers. That's the whole point. They use 
their /own/ servers to send outbound emails, and that's why those emails 
need to be authenticated with either SPF or DKIM for them to pass the 
companies' DMARC policies.


You asked what the use case is. The use case was explained to you. It's 
not useful to come back and say, "Well, I mean, if they did things 
differently, then this wouldn't be an issue." They're not doing things 
differently, and they don't want to do things differently. It's our job 
to facilitate them being able to make their emails look the way they 
want to securely. It's not our job to tell them that they can't make 
their emails look the way they want to or can't employ third-party 
service providers to send out emails on behalf of their domains. Either 
of those is a non-starter.


Jonathan Kamens


___
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] Ranked domains that advertise RUA addresses and then bounce aggregate reports sent to them

2020-04-16 Thread Jonathan Kamens via dmarc-discuss 
On 4/15/20 3:48 PM, John Levine wrote:
> In article <65960f35-16b5-7889-5db1-c5c678015...@kamens.us> you write:
>> For your edification, below, in domain rank order (from the
>> https://domcop.com/openpagerank/ API), are the ranked domains that have
>> bounced at least one DMARC aggregate report my mail server has tried to
>> send them since I started tracking this in September 2018.
>>
>> There are a lot of domains on this list that are big enough that they
>> really should be able to handle something as critical as not bouncing
>> aggregate reports sent to the email address they advertise for them.
> One rejected report in about 500 days is an 0.2% bounce rate.  That seems
> a bit extreme.
I said /at least/ one, not /exactly /one. Once a site bounces a report I
add them to an exclude list and stop trying to send them reports, so I
don't actually know how many bounces any of these domains generated. I
doubt it's just one.
> Do you have an idea of why they're being rejected?  Yahoo in
> particular sometimes has bad days (I think due to DDoS) and defers or
> fails to accept mail to anyone.  It's nothing personal.

Reports whose delivery were deferred don't show up on my list; it's just
for reports that were permanently bounced. And personally, I don't care
why they bounced. Rejecting the reports means more work for the servers
sending them and the people who maintain those servers, assuming that
those people are trying to do the right thing as opposed to just
black-holing bounces. If a site doesn't want to process the reports for
whatever reason then they should accept them and throw them away, not
bounce them. In my opinion It's a bad look for domains that can't manage
even that reliably.

When I first started maintaining the list of domains not to generate
reports for, I did keep track of why they were bouncing, though I don't
do that anymore. Here are some of the bounce causes I saw (not a
comprehensive list, obviously):

youtube.com: rate limiting on the RUA mailbox
google.com: rate limiting on the RUA mailbox
flattr.com: message content rejected
trendmicro.com: connection timed out (for several days)
pobox.com: DMARCIFY appears to be out of commission; Pobox has since
switched to fastmaildmarc.com

  jik

___
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] FYA: Class action administrators send out millions of emails that violate DMARC and are rejected

2019-08-03 Thread Jonathan Kamens via dmarc-discuss 

I though y'all might find this amusing.

The class action administrators of the lawsuit against Experian for the 
breach of 15 million T-Mobile customers' data revealed in 2015 just sent 
out emails to the millions of class members notifying them about how to 
collect their benefits under the lawsuit settlement.


The domain the emails came from has a p=reject pct=100 DMARC policy, and 
the emails failed DMARC checks, since neither SPF nor DKIM was aligned: 
the From: line of the emails said "@classact.com", while both the DKIM 
signature and envelope sender domain said "bluehornet.com".


This means that most of the victims sent these emails will never see them.

It gets better. When I attempted to email the lawyers from the lawsuit 
to notify them about the problem and ask them to fix it, my email was 
bounced for two of the recipients, because the email list for the 
lawyers is hosted on outlook.com and it modified my message and broke 
the DKIM signature before forwarding it on to those two recipients.


SMDH.

You can read more details on my blog 
 
if you're curious.


  jik


___
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] What is the end goal of DMARC?

2018-10-10 Thread Jonathan Kamens via dmarc-discuss 
This is a spin-off from the thread I started yesterday about p=none vs 
"p=reject; pct=0".


I thought the goal of DMARC was that eventually the maintainer of every 
domain on the internet that shows up in the From: line of email messages 
will be able to reliably tell the rest of the internet which of those 
emails are legitimate and which are forged, and the rest of the internet 
will therefore be able to divert the forged messages so users don't see 
them. In short, I thought the goal of DMARC was to eventually make it 
pointless for spammers to forge emails from real domains because users 
simply would not see them in a world where DMARC is deployed everywhere.


Some of the responses in the thread I started yesterday suggest to me 
that this goal which I thought was the point of DMARC is not, in fact, 
what anyone expects DMARC to achieve.


For example, one poster claimed that no "mailbox provider" should ever 
be using "p=quarantine" or "p=reject" in their DMARC policy. This 
confuses me. If the mailbox providers, i.e., the domains which host the 
majority of users and presumably generate the majority of emails, are 
not expected to be able to definitively assert which emails claiming to 
be from them are legitimate, even in a world where DMARC is properly 
implemented everywhere, then what's the point? Again, what's the goal?


Several posters talked about how rewriting errors to preserve DMARC 
compliance in forwarded messages "degrades the user experience" and 
therefore it should only be done when absolutely necessary. However, if 
the eventual goal is for everyone to be using DMARC and generating 
emails that pass DMARC, then either rewriting headers or resigning 
messages with ARC is eventually going to be required for every email 
message that transits a third-party server without a DKIM signature, or 
which is modified in a way that breaks the DKIM signature, so since 
we're trying to expand the adoption of DMARC, shouldn't we be swallowing 
that bitter pill and doing the rewriting or adding ARC signatures so 
that users get used to the "degraded" experience that they're going to 
have to tolerate in the future in exchange for making email more secure 
for everyone?


And let's talk about ARC signatures for a minute. As I pointed out in a 
message yesterday -- and I don't think anyone has contradicted me, 
unless I missed it -- an essential element of ARC as I understand it is 
that every server that receives email has to maintain a list of all the 
domains whose ARC signatures they trust. There are essentially an 
infinite number of internet domains, and while it's true that most of 
them don't forward emails, surely there are thousands if not tens of 
thousands that do. I don't see how any system that relies on system 
administrators making trust decisions on a case-by-basis about thousands 
of domains is workable or scalable. I also don't see what the path of 
entry is for the extremely typical case of a small or medium-sized 
company that wants their users to be able to configure their company 
email accounts to forward their emails somewhere else. ARC is not going 
to work for them because how are they going to convince behemoth sites 
like Gmail, AOL, Yahoo, etc., to trust their ARC signatures?


What am I missing here? How is this all expected to work when we're in 
the deployed-everywhere phase of DMARC and ARC rather than the 
still-toying-with-people's-expectations phase?


Thanks,

Jonathan Kamens


___
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] "p=none" vs. "p=quarantine; pct=0"

2018-10-09 Thread Jonathan Kamens via dmarc-discuss 

On 10/9/18 2:14 PM, Shal F via dmarc-discuss wrote:

> I find this bewildering and frustrating both for domains attempting to
> roll out DMARC ...

If you have users who participate in mailing lists, that is, if you're 
a mailbox provider, I think it can be fairly argued that you should 
not even consider using quarantine or reject policy. The bad example 
of some major mailbox providers notwithstanding.


It can also be fairly argued that the maintainers of servers that host 
mailing lists should get off their asses and fix their software to 
rewrite headers for domains that have DMARC policies, and that they have 
no incentive to do this as long as the mailbox providers aren't using 
p=quarantine or p=reject.


I mean, how many years have we had DMARC now? I really can't see any 
excuse for anybody running a mailing list server not to have solved this 
problem by now. It's been long enough already.


Or, at least you should defer that decision until it is seen whether 
ARC solves the mailing list problem for your users.


Honestly, I'm having trouble understanding how ARC is going to solve the 
problem satisfactorily. As I understand it, every site that actually 
checks DMARC headers on inbound emails is going to have to maintain a 
list of all the ARC signers they trust. That seems like an intractable 
problem and a nightmare to administer. How will administrators know 
which ARC signers are trustworthy? If I run a small Mailman server for 
my friends and I, even if I run OpenARC on it and generate ARC seals, 
nobody's going to bother adding my domain to their trusted ARC signer 
list, so basically I can't participate in ARC. I've been on the internet 
a long time and I can't say I at all like the idea of a standard which 
will only actually be usable by big service providers.


  jik

___
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] Aggregate report 'loop'

2018-10-09 Thread Jonathan Kamens via dmarc-discuss 
This problem is also avoided by using a third-party processor for your 
aggregate and forensic reports, so they aren't coming into your domain, 
right?


On 10/9/18 7:42 AM, Juri Haberland via dmarc-discuss wrote:

On 09/10/18 12:00, Paul Smith via dmarc-discuss wrote:

[...]

Several days ago, we received a marketing email from 'johnlewis.co.uk'.
Our server dutifully sent a DMARC aggregate report back to them as their
'rua' record says.

Then, the next day, we get an aggregate report back from them - with one
message in - our aggregate report

So, our server sends back an aggregate report back to them - with one
message in - their aggregate report

{...]

The recommended way to prevent such "loops" is to send your reports from a
subdomain with a DMARC record that has no 'rua' tag. That way you won't
trigger new reports for your report.


Cheers,
   Juri
___
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 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] "p=none" vs. "p=quarantine; pct=0"

2018-10-09 Thread Jonathan Kamens via dmarc-discuss 
As I'm sure the folks on this list are aware, apparently some ESPs and 
software maintainers have chosen to behave differently when forwarding 
emails (most notably to mailing lists) depending on whether the sender's 
domain DMARC policy is nonexistent or *p=none*, vs. *p=quarantine* or 
*p=reject*.


In particular, the ones that I know about are Google Groups and GNU 
Mailman, both of which have decided to rewrite From: lines when they see 
*p=quarantine* or *p=reject* but leave them intact when they see no 
DMARC policy or a policy with *p=none*.


I find this bewildering and frustrating both for domains attempting to 
roll out DMARC and for the administrators of mail servers attempting to 
enforce it on incoming emails.


From the outbound email point of view, what good does it do to get 
aggregate reports telling you messages forwarded through mailing lists 
weren't DMARC compliant when you can't do anything about it and when 
messages sent through those same mailing lists will magically become 
compliant when you switch from *p=none* to *p=quarantine*? This is 
especially true since you can't actually /know/ that those messages are 
going to magically become compliant, because you can't know which 
mailing list platforms play this game.


From the inbound email point of view, having just deployed the current 
beta release of OpenDMARC on my personal (not Quantopian's) mail server 
(Incidentally, an aside: is anybody actually /maintaining/ OpenDMARC? 
There are multiple significant bugs in it that have been reported with 
patches on Github and the maintainers there have been radio silent for 
months), I am carefully monitoring the logs, both to confirm that it is 
behaving properly and so that I can detect and report any problems to 
the OpenDMARC maintainers (I've already submitted several bug reports 
and patches). Several times a week I get a "/domain/ fail" log message 
from OpenDMARC and I have to investigate it, only to discover that the 
only reason for the failure is because someone on my server received a 
message through a mailing list and the sender domain's DMARC policy is 
*p=none*.


I see people behaving badly here in both directions. In my opinion, 
servers that do message forwarding should rewrite headers for DMARC 
compliance whenever there is a DMARC policy, not just when the policy is 
*p=quarantine* or *p=reject*. And on the other end, given that the 
servers that do forwarding /aren't/ behaving that way, nobody should be 
using *p=none* in their policy; they should instead use *p=quarantine; 
pct=0* to force their headers to be rewritten during forwarding.


Am I missing something here?

  Jonathan Kamens


___
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] RUA vs RUF reports

2018-05-30 Thread Jonathan Kamens via dmarc-discuss 

Can you elaborate on how typosquatting is relevant to this? I'm confused.

If one of your users sends email /to/ a typosquatted domain, and you've 
DKIM'd the email properly on the way out, then you're not going to get 
failure reports because the email does, in fact, pass DMARC.


If someone sends email /from/ a typosquatted domain, then you're not 
going to get failure reports because it's not your domain in the From line.


I'm just... confused. I don't understand what scenario you are implying. 
Can you clarify for me?


Thanks,

Jonathan Kamens

On 5/30/18 5:17 PM, Elizabeth Zwicky wrote:
It might be that you are correct about GDPR, but this has been a 
concern well before the GDPR, and whether or not it concerns the Data 
Protection Authorities, it concerns our privacy lawyers. Typosquatting 
is, after all, a thing.


Elizabeth
*
*
*Elizabeth Zwicky*
Mail Abuse Distinguished Engineer
My oath: 濾 ☕️ 




On Wednesday, May 30, 2018, 2:02:45 PM PDT, Jonathan Kamens via 
dmarc-discuss  wrote:



On 5/30/18 4:22 PM, John Levine wrote:

2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.

They're sent to whoever some ruf= tag points to.  I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it.  Sounds like total strangers to me.


I don't think you can be held responsible if a "total stranger's" 
email ends up in your inbox because they put your domain in the From 
line of the email without your authorization. Furthermore, of the 
cases you mentioned ("forged", "typo", "configuration error"), I don't 
think anything but "forged" happens with sufficient frequency to be 
worth your concern or the concern of the European Union's member 
states' Data Protection Authorities.


  Jonathan Kamens


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org <mailto: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 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] RUA vs RUF reports

2018-05-30 Thread Jonathan Kamens via dmarc-discuss 

On 5/30/18 4:22 PM, John Levine wrote:

2) The people receiving the failure reports aren't "total strangers."
They are either (a) the same people who run the email infrastructure (if
failure reports are handled internally), who are presumably authorized
to look at email headers while troubleshooting issues, or (b)
third-party data processors (to use the GDPR terminology), which are
permitted as long as how they are using the data is disclosed to users.

They're sent to whoever some ruf= tag points to.  I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it.  Sounds like total strangers to me.


I don't think you can be held responsible if a "total stranger's" email 
ends up in your inbox because they put your domain in the From line of 
the email without your authorization. Furthermore, of the cases you 
mentioned ("forged", "typo", "configuration error"), I don't think 
anything but "forged" happens with sufficient frequency to be worth your 
concern or the concern of the European Union's member states' Data 
Protection Authorities.


  Jonathan Kamens


___
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] RUA vs RUF reports

2018-05-30 Thread Jonathan Kamens via dmarc-discuss 

Two comments:

1) Most of the failure reports I've seen haven't included the message 
body, they've only included the headers. So the exposure is limited. I 
assume limiting the exposure is the whole reason why the reports don't 
include message bodies.


2) The people receiving the failure reports aren't "total strangers." 
They are either (a) the same people who run the email infrastructure (if 
failure reports are handled internally), who are presumably authorized 
to look at email headers while troubleshooting issues, or (b) 
third-party data processors (to use the GDPR terminology), which are 
permitted as long as how they are using the data is disclosed to users.


There /could be/ a GDPR issue if failure reports are sent to a 
third-party processor /and/ that isn't disclosed to the user, but it 
isn't /ipso facto/ a GDPR issue to use a third-party processor to manage 
failure reports.


  jik

(I know more about the GDPR than I would like, and less than I should. :-/ )

On 5/30/18 10:56 AM, Richard via dmarc-discuss wrote:



Date: Tuesday, May 29, 2018 19:35:27 -0400
From: John Levine via dmarc-discuss 

In article

you write:
I'm surprised to learn of the low value of failure reports.

It's a lawyer thing.  Failure reports send copies of your users'
mail to total strangers.  Maybe those strangers had something to do
with that mail, maybe not.  You can make various arguments about
why even if the strangers didn't have anything to do with the mail
they should get to see it anyway, but you know how lawyers are,
always telling you to spend $1000 to defend against a $10 risk.



I realize that enforcement of GDPR is still a work in progress, but:

   > Failure reports send copies of your users'
   > mail to total strangers.

would seem to run directly against its intent.


___
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 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:

[dmarc-discuss] Get failure reports without actually rejecting messages?

2017-07-11 Thread Jonathan Kamens via dmarc-discuss 
We've recently started using DMARC for our domain, and we're doing our
best to get everything passing before we switch from p=none to p=reject.
Unfortunately, the information we're getting from the aggregate reports
that various domains are sending us is not always sufficient for us to
figure out DMARC failures. We thought we could address this by putting
an "ruf" field into our DMARC record, but after doing that, we're still
not getting any failure reports. After further research, I think this is
because failure reports aren't actually generated for p=none, i.e.,
they're only generated for p=reject.

Is that correct? If so, that seems like a real problem that I don't know
how to get past. Here's the thing... I'm pretty sure most of the DMARC
failures we're seeing are actually legitimate email messages, but like I
said, we don't have enough information from the aggregate reports to be
able to figure out why they're failing DMARC. There's a chicken-and-egg
problem here: I can't get enough information to figure out what's going
wrong with these emails until I enable p=reject, and because I don't
want to bounce legitimate emails, I can't enable p=reject until I've
figured out what's going wrong with these emails. So, what am I supposed
to do?

Also, another thing I'm confused about from reading the available
information about DMARC is whether, once we enable p=reject, we'll get
copies of /all/ messages that are rejected due to DMARC failures, or
whether instead it's up to the discretion of each receiving MTA to
decide whether to generate a failure report. If the former, then at
least theoretically, we could enable p=reject briefly, collect some
sample DMARC failure reports to troubleshoot, then disable p=reject,
troubleshoot the failures, and forward them on to their intended
recipients, so no email ends up getting lost. But if it's up to the
discretion of the MTA whether to generate a bounce report, then even if
we only enable p=reject for a short period of time, we could end up
causing legitimate emails to be lost, and we'd really rather not have
that happen.

Thanks,

Jonathan Kamens


___
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)