> On Nov 14, 2016, at 2:42 PM, Terry Zink via dmarc-discuss > <[email protected]> wrote: > >> Well, DMARC addresses one particular vector - we still need to find more >> effective ways >> to address cousin domains, display name abuse, etc. > > I didn't mean cousin domains, I mean domains that are not the same but have a > relationship (e.g., one is a vendor of the other). They both have weak > authentication records (no DMARC, or DMARC + p=none), and then one of them > gets spoofed. > > So yes, the fix is to publish a stronger DMARC policy, but lots of domains > who publish DMARC have a weak policy. It's hard to get to p=reject/quarantine > if you are not a big company and are doing it yourself.
But (by default) overriding a p=none to something stronger is punishing those who at least have heard of DMARC in favor of not publishing a record at all, and thus not gathering enough data to be able to get to reject or quarantine. It can take a long time to get beyond p=none depending on internal priorities, politics, size of problem to begin with… if I had thought there was any reasonable expectation of having my p=none get overridden by default (especially as they don’t seem to be sending any reports?) I wouldn’t have been able to start on this path at all. > > > -----Original Message----- > From: dmarc-discuss [mailto:[email protected]] On Behalf Of > Steven M Jones via dmarc-discuss > Sent: Monday, November 14, 2016 11:24 AM > To: [email protected] > Subject: Re: [dmarc-discuss] FortiNet’s FortiMail DMARC implementation > > On 11/14/2016 10:33, Terry Zink via dmarc-discuss wrote: >> In my experience, domains sit on p=none for a long time, and in the meantime >> a lot of other senders send email as them - most legitimate but some >> malicious. This setting is designed to catch the malicious. > > Maybe I need to make that a more central focus in 2017... > > >> So, either (a) you rely upon DMARC proper but have to add additional layers >> to catch the rest of the phish, or (b) you go hyper-aggressive and then add >> layers (overrides) to allow the legitimate email. >> >> Both options are not great, although having to set up override after >> override after override is management pain as it is prone to false positives. > > If the option were there to make those overrides I'd be more supportive, but > it didn't sound like that was the case with this particular product/service. > If somebody with access could clarify, I'd appreciate it. > > >> I used to say that I would probably treat your own domain(s) as >> p=quarantine/reject but respect the setting for domains you don't own. But >> in the past month or two, I've seen plenty of "other-domain" spoofing, that >> is, spammers/phishers spoofing domains with weak authentication policies and >> getting in that way. > > Well, DMARC addresses one particular vector - we still need to find more > effective ways to address cousin domains, display name abuse, etc. Some > products/services have moved in that direction, and there are some efforts > trying to determine if there's an approach amenable to being standardized. > > --S. > > > _______________________________________________ > dmarc-discuss mailing list > [email protected] > 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 [email protected] 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)
