Michael Adkins <[email protected]> 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? > >The large financial institutions who participated in the DMARC effort >did >not express this concern. > If the group of people that participated understood everyone's concerns well enough to represent them in the private phase of DMARC's development, why are we bothering to talk now? Testing the new thing before you turn off the old thing is such a garden variety, normal thing to do that I am completely mystified why anyone would ever design a protocol that precludes this. My level of confusion is only increased by the fact that I still don't understand a single technical reason why this would be a good idea. >>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. What's the downside of this? 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)
