> On Sep 26, 2016, at 4:34 PM, Franck Martin <fmar...@linkedin.com> wrote: > > We do enforce inbound policy, in fact this has been very useful, when you > send to yourself a copy of the failure reports, It allows you to find > problems with your email streams before they become real problems (as well as > all the details helping you to fix them).
Yep, I’ve been collecting inbound reports via Agari’s reflect product, as our MX provider doesn’t (yet???) send reports. For the last couple of weeks I’ve been at 95-98.5% DMARC compliant for my own email coming in from the outside, as I’ve been working with all of our legit 3rd parties. > > cf: https://github.com/linkedin/lafayette/wiki/Screenshots > > I had to put one or two companies in a local policy exception, but they were > emailing only our employees, not the whole world. > > Many third parties can abide to your DMARC policy, but you need to spell it > out what you want them to do, as many do not understand what DMARC is. Yes. I’ve been ramming DKIM down the throat of my vendors, as I have scaling concerns with SPF (plus alignment is a huge issue). However… we have staff on non-DMARC-“fixing” mailing lists, like IETF, OpenSSL, etc. How are companies dealing with that while waiting for ARC? Are you whitelisting the “well known” mailing list servers? My original thought was to put mailing list users onto a non-DMARC protected domain, but I see users from Microsoft, Google, LinkedIn on those same lists, so either they’re not enforcing inbound (but LinkedIn and Microsoft are), or you’re whitelisting - right? If so, is there a place to share those IPs, or is everyone on their own to figure out what IPs for even the most common lists are? Thanks John > > I have used that FAQ entry a lot with all 3rd parties: > https://dmarc.org/wiki/FAQ#My_organization_uses_third-parties_senders.2C_how_can_I_get_them_DMARC_compliant.3F > > On Mon, Sep 26, 2016 at 9:03 AM, Payne, John <jpa...@akamai.com> wrote: > >> On Sep 22, 2016, at 10:34 PM, Franck Martin <fmar...@linkedin.com> wrote: >> >> https://engineering.linkedin.com/email/dmarc-new-tool-detect-genuine-emails >> https://engineering.linkedin.com/email/dmarc-moving-monitor-reject-mode >> >> google.com is p=quarantine >> yahoo-inc.com is p=reject >> microsoft.com is p=quarantine >> paypal-inc.com is p=reject >> >> You will find other resources at dmarc.org > > google.com is p=reject FWIW > > I’m interested in how these companies got to that point. What workarounds > are they relying on if any? > Are they enforcing DMARC policies inbound? > > >> As for the Gmail question, I think it is linked to the release of ARC. > > So I’ve heard. I hope that turns out to be useful for the rest of us :) > >> >> On Mon, Sep 19, 2016 at 12:06 PM, Payne, John via dmarc-discuss >> <dmarc-discuss@dmarc.org> wrote: >> >> > On Oct 22, 2015, at 3:43 PM, Payne, John <jpa...@akamai.com> wrote: >> > >> > >> >> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss >> >> <dmarc-discuss@dmarc.org> wrote: >> >> >> >> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss >> >> wrote: >> >>> The fun is moving to ARC >> >>> >> >>> https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/ >> >> >> >> Sad to see that Gmail plan to move to p=reject >> > >> > I’m hoping that it encourages the mailing list folk who have been >> > reluctant to become DMARC safe to reconsider, whether thats ARC or >> > wrapping. >> > As an enterprise hoping to go p=reject, this is potentially a big deal for >> > me :) >> >> >> I’m not exactly in the loop, but besides this article almost a year ago, I >> haven’t seen anything else about gmail going p=reject… and it’s now 3 months >> past the advertised date. >> Any word there? >> >> Somewhat related (to my earlier post) - are there any _enterprises_ on this >> list that have experience or are currently attempting to either go p=reject >> or enforce DMARC policies inbound? >> >> Thanks >> 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) >> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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)
