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.


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...


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.  :-(


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

Reply via email to