I really appreciate your thoughts on this.
The amount of DMARC data for a large decentralized university is
daunting, so my approach is to compartmentalize issues that can be
addressed. I'm looking at securing the second-level domain first, with
the intention of encouraging campus entities to use subdomains for their
non-p2p mail. This will allow us to correlate the campus entity to the
DAMRC reports for their subdomain (which is impossible to do if everyone
is squatting on the second-level domain), and encourage the use of
strong DMARC policies to protect their subdomains from abuse.
Looking at the data for the second-level domain, I see 322 obvious
forwarding/list services that break DKIM signatures. There are
tens-of-thousands of servers sending indirect mail flow, but it's mostly
mailbox hosters autoforwarding mail for users (with, I'm sure, a lot of
distribution lists mixed in to that flow) but I will focus on that
problem later.
So, of the 322 obvious list services. How many of them do I need to
reach out to convince them to upgrade their lists to rewrite in a DMARC
compliant fashion? I was hoping that there was a way to trigger a
subset of that 322 so that:
1) I know how many of them are "dormant" DMARC compatible. Check them
off the list and move on to the problematic list servers.
2) When people start seeing headers rewritten we can use that as an
attention mechanism to make people aware of email authentication as a
concept, and convince people to tackle the other indirect mail flow issues.
I'm looking for ways to start tackling these issues, get the attention
of a hundred thousand people to convince them to stop squatting on the
second-level domain, all without knowingly triggering their mail to be
treated as spam.
Jesse
On 4/6/2018 2:30 PM, Brandon Long wrote:
Well, that's the nature of production changes. The best you can do is
what you have available with your tools and the standards.
At some point, you've exhausted the corrections you can make based on
p=none, and you need to make the next step, which is p=quarantine pct=0.
You should stay at that point for as long as it's useful. You can see
what monitoring you can do while at that stage, see if there's any way
to measure your production mail traffic to see if there's major changes
in traffic.
There are obviously limitations built into this, given that this mostly
effects what other systems do with your traffic and the time frame
before you get feedback, but that's the break.
Theoretically, you could try it on some staging/limited/testing domain
first, but you probably won't have the volume necessary. You can come
up with a list of services you care about and test them directly on a
test domain. You could theoretically set up some end-to-end test (send
email from foo to bar and monitor whether it gets there, and do so with
a new email every 5 minutes)
If you consider any single email going awry a problem, then DMARC is
probably not what you want to do anyways, since there will never be 100%
non-false positives with DMARC. That said, whether your mail is
accepted by any system ever is somewhat out of your hands, and improving
your chances of other servers accepting your legitimate email might
depend on setting up DMARC to clean out the garbage...
Brandon
On Fri, Apr 6, 2018 at 10:48 AM Jesse Thompson <jesse.thomp...@wisc.edu
<mailto:jesse.thomp...@wisc.edu>> wrote:
Well, that's the crux of the issue. If I make this change and a
DMARC-incompatible mailing list forwards a message to Gmail, the message
might be treated as spam. But I don't know which mailing lists are
DMARC-incompatible until after I make this change. I'm in a state of
paralysis. :-(
Jesse
On 4/6/2018 10:57 AM, Brandon Long wrote:
> I know when I suggested it originally on this list, some folks found
> some bugs, which we fixed.
>
> That said, the spam team seems to reinvent dmarc parsing periodically
> (on top of our main dmarc processing), and it's often less than
> correct. In this case, it'll just mean that mail that doesn't
pass will
> more likely be marked as spam, so it's probably mostly safe if you've
> gotten most of your sources covered. And let me know, I can
hassle them
> again if it's broken again.
>
> Brandon
>
> On Fri, Apr 6, 2018, 8:31 AM Jesse Thompson
<jesse.thomp...@wisc.edu <mailto:jesse.thomp...@wisc.edu>
> <mailto:jesse.thomp...@wisc.edu
<mailto:jesse.thomp...@wisc.edu>>> wrote:
>
> Great, thank you! I'll give it a whirl and report back if
anything
> negative happens.
>
> Jesse
>
> On 4/5/2018 7:42 PM, Todd Herr via mailop wrote:
> > We saw no negative side effects when we did it here for our
> domains, and
> > we did it for precisely the reason you're planning to do
it, to
> trigger
> > Google Groups.
> >
> > On Thu, Apr 5, 2018 at 7:00 PM, Jesse Thompson
> <jesse.thomp...@wisc.edu <mailto:jesse.thomp...@wisc.edu>
<mailto:jesse.thomp...@wisc.edu <mailto:jesse.thomp...@wisc.edu>>
> > <mailto:jesse.thomp...@wisc.edu
<mailto:jesse.thomp...@wisc.edu>
> <mailto:jesse.thomp...@wisc.edu
<mailto:jesse.thomp...@wisc.edu>>>> wrote:
> >
> > Does anyone know of any negative side effects of
setting a DMARC
> > policy: p=quarantine pct=0 ?
> >
> > Is it equivalent to: p=none ?
> >
> > I'm curious because I want to trigger Google Groups
(and maybe
> > others list forwarders?) to rewrite the From in a
DMARC compliant
> > fashion *prior* to changing the domain's DMARC
policy... to avoid
> > the "leap of faith" that p=none's monitoring mode was
supposed to
> > alleviate.
> >
> > Thanks,
> > Jesse
> > _______________________________________________
> > mailop mailing list
> > mailop@mailop.org <mailto:mailop@mailop.org>
<mailto:mailop@mailop.org <mailto:mailop@mailop.org>>
> <mailto:mailop@mailop.org <mailto:mailop@mailop.org>
<mailto:mailop@mailop.org <mailto:mailop@mailop.org>>>
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >
<https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop>
> >
> >
> >
> >
> > --
> >
> > *todd herr**
> > **sr. delivery engineer
> > www.sparkpost.com <http://www.sparkpost.com>
<http://www.sparkpost.com>
> <http://www.sparkpost.com>*
> > *twitter* @toddherr @sparkpost
> >
> > *tel* 415-578-5222 x477
> > *mobile* 703-220-4153
> > *email* todd.h...@sparkpost.com
<mailto:todd.h...@sparkpost.com> <mailto:todd.h...@sparkpost.com
<mailto:todd.h...@sparkpost.com>>
> > <mailto:firstname.lastn...@messagesystems.com
<mailto:firstname.lastn...@messagesystems.com>
> <mailto:firstname.lastn...@messagesystems.com
<mailto:firstname.lastn...@messagesystems.com>>>
> >
> >
> >
> > _______________________________________________
> > mailop mailing list
> > mailop@mailop.org <mailto:mailop@mailop.org>
<mailto:mailop@mailop.org <mailto:mailop@mailop.org>>
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org <mailto:mailop@mailop.org>
<mailto:mailop@mailop.org <mailto:mailop@mailop.org>>
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
