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.
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.
--Steve.
_______________________________________________
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)
