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> 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>> 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>>> 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>> > > > 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:firstname.lastn...@messagesystems.com > > <mailto:firstname.lastn...@messagesystems.com>> > > > > > > > > > > > > _______________________________________________ > > > mailop mailing list > > > 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> > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
