Steven M Jones <[email protected]> wrote:
>My apologies in advance if I've missed something crucial in trying to >catch up with this thread... > > >On 07/06/2012 07:42 PM, Scott Kitterman wrote: >> On Saturday, July 07, 2012 02:10:18 AM Franck Martin wrote: >>> Finally, as you had reports, did you notice a difference in the way >your >>> emails were handled (I may have missed that in the thread). >> There's no way to know if they were handled differently or not. I >didn't >> notice anything, but the amount of direct email I have with the >current DMARC >> reporters is very small. > >This "no way to know" situation has been one of my problems with the >pre-DMARC scenario. Do you base your satisfaction with SPF/ADSP policy >assertions on data showing they were having the desired impact in >preventing fraudulent use of a domain - or any other outcome, for that >matter - or on a lack of negative feedback as filtered through your >users? I confess that as a former sysadmin I've lived and died by the >"nobody's complaining, it must be okay" mechanism. But I prefer things >I >can usefully measure and track, and DMARC is a huge step in that >direction. > I know the Joe job backscatter abruptly stopped about a month after I published an SPF record ending in -all, so I have clear evidence dating from when I deployed SPF that those policies had a deterrent effect. As I previously mentioned, virtually all the traffic I see in DMARC reports is from mailing lists or generated via web site activity (I can tell you a LOT of people read debian-devel through Gmail. One message on that list resulted in (IIRC) 3000 messages on my next DMARC report). Since I'm not in direct correspondence with those subscribers, there is no way for me to know how their experience changed. It is also not possible to know, in advance, if the deterrent effects of SPF -all records would be diluted by DMARC none overriding it. This is not an issue for the group that designed DMARC. AFAICT, the design team involved people from domains that are specifically targeted. A lot of smaller domains have benefitted from no longer being used as a random domain in some spoofing campaign. >On 07/06/2012 07:42 PM, Scott Kitterman wrote: >> Here's another use case to consider: >> >> A large financial institution has invested a lot of effort into >separating it's >> human and transactional domains, deployed SPF, DKIM, and ADSP (on the >> transactional domains) and is comfortable with it's situation. Now >you tell >> them they should deploy DMARC. How do they evaluate DMARC and see >what the >> impact of publishing DMARC reject policies would be without messing >up the >> stuff they've already spent 5 years working on? >> >> By the current definition, they can't. Why not? If you want to >split out >> monitoring from take no policy action of any kind into two separate >things, >> that's fine, but I really think you need a monitor policy that means >exactly >> that and no more. > >First, I applaud that company. Maintaining that operational state takes > >a lot of on-going effort and executive support, especially when >somebody >new joins and says, "Just do it" once a quarter. Second, I'm not >arguing >one way or the other about a non-overriding monitoring policy. > >But my day job is working for a VLFI; there was also some mention of >VLFI input into DMARC, which puts me in the crosshairs. > >As to publishing DMARC reject policies - you'd introduce DMARC policies > >just like any other roll-out with potential production impact, as >gradually as possible. Do a non-production domain or two and measure. >Do >a few more, wait and see. After endless meetings and risk assessments >with the business partners, do one lesser production domain and measure > >like crazy with a finger on the back-out switch. Then you might work up > >a schedule for further introduction... Like everything else, you >minimize risk and measure impact at each step. How is this scenario any > >different? > > >No one person or group is going to think of everything - I demonstrate >that every day. That's why DMARC is being tried in public, with >feedback >based on real world experience. I personally appreciate all of this >discussion in hopes that we make sure DMARC is as broadly useful as >possible. I would image you would prefer to be able to collect data to understand the impact before you flip the switch. I used a bank as an example because I know financials have been in the forefront of email authentication deployment. It could be any large entity with a complex mail architecture. Scott K _______________________________________________ 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)
